Storage with Nitro Sandboxes: clarify which CSI volumes are supported (third-party NFS volumes fail)

Open Beginner friendly
  • Is something wrong?
#1,259 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
68/100
Issue type
Documentation
Clarity
Mostly clear
Activity status
Active
Tech stack
aws, kubernetes
Domain
cloud, documentation

Research direction

Find the source for the EKS User Guide page “Storage with Nitro Sandboxes” at https://docs.aws.amazon.com/eks/latest/userguide/sandboxing-storage.html and review its CSI driver and EFS sections. Check the related feature requests for NFS and block volumes linked in the issue before deciding what support can be stated. Update the page to identify supported volume types and clarify the status of third-party node-mounted volumes and the listed untested device types.

Written by the indexing model from the issue text.

Description

Page: https://docs.aws.amazon.com/eks/latest/userguide/sandboxing-storage.html ("Storage with Nitro Sandboxes")

What the page says now

The first sentence says pods in Nitro Sandboxes "support several storage options through standard Kubernetes CSI drivers". The sections then cover EBS, EFS, tmpfs-backed CSI drivers (Secrets Store, cert-manager), and standard volume types. The EFS section notes that the NFS mount is performed inside the sandbox.

What is unclear

The page does not say what happens with a CSI driver that is not listed, in particular a third-party driver that mounts an NFS filesystem on the node. "Standard Kubernetes CSI drivers" can be read as covering any CSI driver.

What I observed (2026-11-10, ap-northeast-1, EKS Auto Mode, Kubernetes v1.36.4)

An NFS PVC provisioned by NetApp Trident (EKS add-on netapp_trident-operator v26.6.2-eksbuild.1, backed by Amazon FSx for NetApp ONTAP) mounted in two ordinary pods on different nodes. The same PVC in a pod with runtimeClassName: isolated-sandbox failed at container init with failed to fulfil mount request: open /var/lib/kubelet/pods/<pod-uid>/volumes/kubernetes.io~csi/<pv-name>/mount: no such file or directory. A sandbox pod with emptyDir and a sandbox pod with an EBS PVC both worked. Details and the manifest are in the feature request below.

Suggested clarification

  1. State which kinds of CSI volumes a sandbox pod can use, and that a volume a third-party CSI driver mounts on the node (for example an NFS volume) is not supported, if that is the intended behavior.
  2. If it is intended, replace "standard Kubernetes CSI drivers" in the first sentence with the list of supported drivers.
  3. State whether iSCSI, NVMe/TCP, multipath, or device-mapper volumes from third-party drivers are supported. I did not test this.

Related feature requests (in aws/containers-roadmap)

Dominant language
Shell
Stars
454
Forks
788
No merged PRs in 30d

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from awsdocs/amazon-eks-user-guide

All issues in awsdocs/amazon-eks-user-guide

Similar issues

More Shell/Bash issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.