NFS Volume is mounted but I cannot read or write files on it

Products

• VMware Tanzu Application Service for VMs

Issue/Introduction

As an Operator or Developer, you are able to bind an NFS Volume Service to my app. When the application starts and you can see that the volume is attached (by running df -h). However, you are unable to read or write files on that volume.

Running ls against the NFS volume mount point or a directory under that does not show any files and indicates a permissions issue. Trying to read or write to a file on the NFS volume indicates a permission issue.

Example

$ ls -l /mnt/files/
ls: cannot open directory /mnt/file/: Permission denied

The NFS Volume Services do not control any aspect of the remote NFS server that includes the owner, the owning group, and the permissions of the remote files. If the permissions of the files on the NFS volume do not match up correctly, you will not be able to read or write them.

By default, the User ID and Group ID of your application running on TAS for VMs will be 2000 and 2000. Thus if the User ID and Group ID on your remote files do not allow access for that UID or GID combination, then you will not be able to Read/Write the files.

Environment

Product Version: 2.2

Resolution

The NFS Volume Services give you the option to set a UID (User ID) and GID (Group ID) when you bind an NFS Volume Service to your application. The NFS driver translates the application's User ID and Group ID (2000 and 2000) to and from the specified UID and GID when sending or receiving traffic to and from the NFS server. This change allows you to interact with your NFS server as a specific user while allowing TAS for VMs to run your application as the standard vcap user and vcap group.

To resolve, review your cf bind-service command and make sure that the uid and gid attributes are being specified.

Example

$ cf bind-service pora myVolume -c '{"uid":"1000","gid":"1000"}'

The UID/GID that you specify, in this example 1000/1000, must match the UID/GID of an actual user and group on your NFS server and that user/group must have permissions to Read/Write the files that your application needs to access.

Note: Support recommends that the owner of volumes/files on the NFS server should not be root. NFS will, by default, downgrade permissions and change the owner from root to the nobody user. This can be unexpected and can prevent Read/Write access of your files. If you use a non-root user, you can avoid this additional step.