How can I get read/write access to NFS share of Synology NAS?
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 byanonuid,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.
Related videos on Youtube
marsilea
Updated on September 18, 2022Comments
-
marsilea over 1 year
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 tocd
into the share and can only get read access by usingsudo
.
Using squash 'map all users to admin' setting, client regular user cancd
into and has only read access to the share. Usingsudo
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
/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 withsudo vi /mnt/nfs/Files/Data/test.file
but cannot write the changes to the file even withsudo
. The vi Error message upon:w!
command is:
"test.file" E212: Can't open file for writing
-
Nephente over 8 yearsNFS 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 over 8 yearsCan 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 clientcd
into the mount and dols -n
. That will list file owners and groups with their respective IDs. You will have to do that withsudo
I guess. Append a line or two of the output to your question, along with the output ofid
(nosudo
!) If you can't evencd
to the mount as a regular user, you will have to check the permissions of the dir you're exporting on the server. -
marsilea over 8 yearsI 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 andid username
. -
marsilea over 8 yearsThankyou, 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..
-
Nephente over 8 yearsIt 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
. AlthoughFiles
belongs toroot
, 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
? -
marsilea over 8 yearsThis 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
withsudo mkdir
so it still belongs to root - not sure if that is correct methodology - I'm still an Ubuntu/Linux beginner. -
Nephente over 8 yearsConcerning
all_squash
. Being not able to write is expected, because you squash toanongid 100
. This group hasr-x
permissions. Withall_squash
, even root and hencesudo
will adopt this GID. I think you made a typo, it should rather beanonid=1026
than1024
...? -
marsilea over 8 years
anonuid=1025
forno_root_squash
;anonuid=1024
forall_squash
. The typo was only in omitting the 'u' inanonuid
. -
Nephente over 8 yearsFine, but the files belong to
UID 102*6*
, so all you get are the group permissions. -
Nephente over 8 yearsTry to set
all_squash
andanonuid=1026
(not 1025) for the export. Re-export withsudo exportfs -ar
, and remount client-side and see if you have write access then. -
marsilea over 8 years@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 withall_squash
set. Thank you!
-
-
marsilea over 8 yearsI 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.