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,552
marsilea
  • 133
  • 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
  • 1
    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 03: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 06:29
  • This is for my home network with just a single user across multiple devices/systems at the current time; not a workplace with multiple users - so I'll stay with nfsv3 for now. Yes, mount point is /mnt/nfs/Files. I must have created /mnt/nfs/Files with sudo mkdir so it still belongs to root - not sure if that is correct methodology - I'm still an Ubuntu/Linux beginner. – marsilea Sep 25 '15 at 07:08
  • Concerning all_squash. Being not able to write is expected, because you squash to anongid 100. This group has r-x permissions. With all_squash, even root and hence sudo will adopt this GID. I think you made a typo, it should rather be anonid=1026 than 1024...? – Nephente Sep 25 '15 at 09:41
  • anonuid=1025 for no_root_squash; anonuid=1024 for all_squash. The typo was only in omitting the 'u' in anonuid. – marsilea Sep 25 '15 at 09:53
  • Fine, but the files belong to UID 102*6*, so all you get are the group permissions. – Nephente Sep 25 '15 at 09:55
  • Try to set all_squash and anonuid=1026 (not 1025) for the export. Re-export with sudo exportfs -ar, and remount client-side and see if you have write access then. – Nephente Sep 25 '15 at 15:39
  • @nephente , your suggestion worked. Would you post it as an answer now? I was hesitant to tinker within the NAS shell but followed your advice and edited /etc/exports. I rebooted it and the exports value remained changed. Now I can write files and change permissions of files within the NAS as if logged in via ssh or browser interface. As I am the only user at the moment, I think I'll use it as it is now with all_squash set. Thank you! – marsilea Sep 27 '15 at 14:25

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,915
  • 1
    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
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,559
Muhammad Aizuddin
  • 31