User ID mapping with NFS on Synology NAS

I have a Synology NAS box (running DSM 5.1), and I've exported a directory via NFS. I'm attempting to mount it on my Ubuntu box.

It mostly works fine, but I'm having issues with user and group mappings. On the Ubuntu box, I am uid 1000 (roger), gid 1000 (roger). On the Synology, I have uid 1026 (roger), group 100 (users).

If I use NFSv3, it uses numeric uid/gid values, which means that the ownership is messed up on the Synology.

If I were to only ever access the NFS mount from the same Ubuntu box, using the same user, this'd be fine, but I also access the directory from a Windows box, using CIFS (SMB), which means that the permissions are wrong.

If I use NFSv4 (mount -o nfsvers=4), with the default settings on the Synology, then files owned by roger.users on the Synology appear owned by roger.users when viewed from the Ubuntu box. This is good.

However, when I touch a file:

roger@ubuntu$ touch /mounts/diskstation/music/foo

It ends up owned by 1000.1000 on the Synology, and shown as owned by nobody.4294967294 when viewed from the Ubuntu box.

Everything I can find on the topic on the Synology forums is either dated from 2011, when NFSv4 wasn't supported, or consists of people asking the same question and then giving up.

For completeness, /etc/exports has:

/volume1/music  10.0.0.0/24(rw,async,no_wdelay,root_squash,insecure_locks,sec=sys,anonuid=1025,anongid=100)

...and I'm mounting it on the Ubuntu box with:

mount -t nfs diskstation:/volume1/music /mounts/diskstation/music/ -o rw,nfsvers=4

I found some hints that the sec=sys might be a problem: Why NFSv4 uid/gid mapping doesn’t work with AUTH_UNIX (AUTH_SYS), but that doesn't have a solution.

Is there a simple way to get around this problem? Is there a more complex (cough Kerberos cough) way to solve this?

Seriously, if Kerberos is the answer, I'll take that hit, but I'd like to know before wasting a bunch of time on it.

Update: while the Synology documentation talks about various Kerberos options, I can't find them in the UI. The release notes state "If Kerberos security flavor is implemented...". I found (but cannot find again) a page which implies that it might not be on certain models. I have a DS211, according to the System Information page. Maybe I'm out of luck?

Solution 1:

For NFSv4 ID mapping to work properly, both client and server must be running the idmapd ID Mapper daemon and have the same Domain configured in /etc/idmapd.conf.

This way your NFS Client sends its ID credentials as [email protected] in the NFS commands on the wire, and your NFS Server idmapper maps that to a user called roger on the NFS Server. The UID and GID don't matter, they are mapped on each system by the idmapper.

However I don't bother with that on my Synology. My Shared Folder has the following permissions:

• Permissions
  • Local Users
    • Admin = read/write
• NFS Permissions
  • Squash
    • Map all users to admin

This results in anonuid=1024,anongid=100 (the admin user and users group) being added to the export in /etc/exports on the NAS.

My NFS Client (which doesn't have the ID Mapper running) sends my NFS commands as my user (1000:1000) and because that UID and GID don't exist on the NAS, it translates my UID and GID to 1024:100 so I am treated as the Admin user who has full permission.

This is a terribly unprofessional and insecure use of NFS for a business environment, but just for me to access my files at home it is an abuse of NFS behaviour which is acceptable to me.

Another option is to make roger's UID and GID the same on the NFS Client and NAS, then you can use NFSv4 without ID Mapping, or you could then use NFSv3 which relies only on UID and GID.

Solution 2:

I've been really struggling with the exact same problem. I went through the huge pain of setting up a Kerberos server with Docker on the Synology, set up the ID mapping, and I still didn't like the behavior. Kerberos is way too over-engineered and difficult to keep working on reboots and automounting. Plus, the default umask of newly created files was 0000, and every new file was created mode 777, no matter what my local umask was.

My solution was similar to suprjami's, but I took it a little further:

• Create a new user with the Synology web UI, name it something like roger.remote. Do the same for a user group, and name it the same as the username.
• On the Synology as root, edit /etc/passwd and change roger.remote's UID to 1000, and GID to 1000
• edit /etc/group and change the group roger.remote to 1000 as well
• In the Synology web UI, set squash to "all users to admin" and save
• As root again, edit /etc/exports and change the UID/GID to anonuid=1000,anongid=1000
• Restart NFS with /usr/syno/etc.defaults/rc.sysv/S83nfsd.sh restart
• This is also a bit hacky -- but chmod 777 /volume1. I had a lot of weird problems with my home directory mounted. KDE wouldn't start because the glibc access() function would return access denied on the mounted NFS directory. (But any subdirectories would work) Firefox also had a similar problem, where it refused to save files to the mounted directory because of the access check. Even though the permissions were correct, and I could touch/create/write files in the mounted directory. Changing the parent /volume1 directory to world writable fixed that dumb problem and fooled the client apps to write to it.
• Remove all of the filesystem ACLs from the share. Through a lot of random experimentation, I found that these ACLs cause problems with the mode mask of files created. I'm not an ACL master, so maybe there's a more elegant solution. As root on the Synology, do synoacltool -del /volume1/myshare. You should see the + symbol removed from the ls -l output.
• Change the ownership of the share to your new user: chown roger.remote:roger.remote /volume1/myshare
• Change the mode to 755: chmod 755 /volume1/myshare
• Mount the volume on the client, test out permissions, it should work! Make sure to touch a file as well and verify your bash umask is applied correctly.

$ umask 
0002
$ cd /mnt/myshare
$ touch test
$ ls -l test
-rw-rw-r-- 1 roger roger 0 Oct 21 18:15 test

On the Synology you should see:

# ls -l /volume1/myshare/test
-rw-rw-r-- 1 roger.remote roger.remote 0 Oct 21 18:15 test

Enjoy!