I have read access only to the mounted NFS share.

With 'no squash mapping' set on the NAS, Ubuntu regular user gets Permission denied when trying to cd into the share and can only get read access by using sudo.
Using squash 'map all users to admin' setting, client regular user can cd into and has only read access to the share. Using sudo does not allow write.

Synology NAS:
DS214> id username
uid=1026(username) gid=100(users) groups=100(users),101(administration)

no squash (no mapping)
DS214> cat /etc/exports

all squash (map all users to admin)
DS214> cat /etc/exports

Ubuntu client:
$ cat /etc/fstab /mnt/nfs/Files nfs rw,user,auto 0 0

$ id username
uid=1000 gid=1000(username) groups=1000(username), <etc>

$ ls -n /mnt/nfs
drwxrwxrwx 9 0 0 4096 Sep 25 01:28 Files

$ ls -n /mnt/nfs/Files
drwxr-xr-x 11 1026 100 4096 Sep 24 22:05 Data

(I originally posted in error that using sudo enabled write access) I can open a file in the mounted NFS share with sudo vi /mnt/nfs/Files/Data/test.file but cannot write the changes to the file even with sudo. The vi Error message upon :w! command is:
"test.file" E212: Can't open file for writing

  • NFS checks access permissions against user ids (UIDs). The UID of the user on your local machine needs to match the UID of the owner of the files your trying to access on the server. Go to the server and look at the file permissions. Which UID (find out with id username) do they belong to and which permissions are set? – Nephente Sep 24 '15 at 15:33
  • Can you even cd into the mount as a regular user? If yes, I suggest the following. To confirm or rebut my suspicion, do the following: On the client cd into the mount and do ls -n. That will list file owners and groups with their respective IDs. You will have to do that with sudo I guess. Append a line or two of the output to your question, along with the output of id (no sudo!) If you can't even cd to the mount as a regular user, you will have to check the permissions of the dir you're exporting on the server. – Nephente Sep 24 '15 at 15:58
  • I couldn't cd into the mount as a regular user. Using Squash on the server to force permissions works as a temporary fix to grant permissions. Investigating server permissions and id username. – marsilea Sep 24 '15 at 17:04
  • Thankyou, I think it would be better to use nfs the correct way rather than just brute force with Squash: 'Map all users to admin' on the server.. – marsilea Sep 25 '15 at 3:59
  • It depends. Do you trust clients and users? If you do not, NFSv3 is not suitable after all, since anyone who has root access to a client, can spoof UIDs. If you need proper authentication, you'd better use SMB. Authentication with NFSv4 requires running a Kerberos which is rather complicated. But nevertheless, your output baffles me... I assume the mount point is /mnt/nfs/Files. Although Files belongs to root, permission allow anyone to do anything. It makes no sense to me why you'd have trouble entering that dir as any user. Maybe post the relevant line from /etc/exports? – Nephente Sep 25 '15 at 6:29

NFSv2/3 handles permissions solely based on UID and GID. File permissions on the server are matched against user- and group ids on client. That is why NFSv<4 is by design insecure in environments where users have root access to the client machines; UID spoofing is trivial in that case.

Note that NFSv4 offers client and user authentication via Kerberos5. If authentication with username and password is needed, it is although often much easier to resort to Samba (SMB/CIFS) instead of setting up a Kerberos, even in pure Linux environments.

To at least prevent escalation of root privileges, NFS shares are exported by default with the option root_squash, which will map all client request coming from root (uid=0, gid=0) to anonuid and anongid. This behavior can be overridden with no_root_squash, granting root access to the export.

Here, we see another drawback. To function properly, NFS basically requires you to have the same UID/GID on all machines. The files you want to access belong to 1026 and have permissions 755. You're user on the client has uid=1000. The GIDs don't match either, so you get world permissions only. Hence no write access.

To resolve this, you could do one of multiple things:

  • On the NAS, change the owner of the files to 1000. You would maybe need to create that particular account. How this will affect other services, I cannot tell.

  • Change the UID of your local user to 1026.

  • Since you are the only one accessing the files on the server, you can make the server pretend that all request come from the proper UID. For that, NFS has the option all_squash. It tells the server to map all request to the anonymous user, specified by anonuid,anongid.

    Add the optionss all_squash,anonuid=1026,anongid=100 to the export in /etc/exports.

Be cautious though, since this will make anyone mounting the export effectively the owner of those files!

If you share your network with people and their clients whom you not trust completely not to make mischief with your files, you really should look into a method of filesharing that offers authentication. In my opinion, Samba is the easiest way to achieve that.

| improve this answer | |
  • I chose NFS because I thought it might have advantages for Linux to Linux, as I'd like to be able to backup the NAS by rsync to external USB drive on the Ubuntu client (Synology's DSM system doesn't offer syncing to USB drive), while keeping file ownership and permission information. A thorough answer, and thanks for the guidance. – marsilea Sep 27 '15 at 18:08

Do showmount -e to see the export options. Permission denied error is coming from the NFS server itself. Try to change option from rw,user,auto to defaults.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.