13

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 writing.

Synology NAS:

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

No squash (no mapping)

DS214> cat /etc/exports
/volume1/Files 10.1.1.2(rw,async,no_wdelay,no_root_squash,insecure_locks,sec=sys,anonuid=1025,anongid=100) `

All squash (map all users to admin)

DS214> cat /etc/exports
/volume1/Files 10.1.1.2(rw,async,no_wdelay,all_squash,insecure_locks,sec=sys,anonuid=1024,anongid=100)`

Ubuntu client:

$ cat /etc/fstab
10.1.1.214:/volume1/Files /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`
Pablo Bianchi
  • 17,371
marsilea
  • 133

2 Answers2

15

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.

Nephente
  • 5,875
0

Do showmount -e 10.1.1.214 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.

Oxwivi
  • 18,499
Muhammad Aizuddin
  • 31