Facts (smile!):
- the Synology DSM NFS server keeps its “mount information files” (etab, rmtab, …) at /var/lib/nfs/rmtab as opposed to /etc, where they “usually” go
- make sure, that /var/lib/nfs/rmtab exists, otherwise you will find ongoing complaints in /var/log/messages; a “touch …/rmtab” will do
- …
“Last resort” resp. “desaster” suggestions – they should always only be of temporary use:
- within /etc/exports set anonuid to the UID of the server-local user, that “deals” with the files in question
- …
I have tried quite a few variations, currently it seems to run (DO NOT TAKE THAT TOO LITERALLY!!!), but I am not very sure, why, and what the implications are.
- http://forum.synology.com/wiki/index.php/How_to_enable_NFS_on_the_Synology_Server – looks a little outdated, but the suggestion to “touch /var/lib/nfs/rmtab”, so that “/usr/sbin/exportfs -a” (in order to make your changes to /etc/exports effective) would not result in an annoying entry in /var/log/messages, is quite nice
- replacing no_root_squash with all_squash within /etc/exports and “…/exportfs -a” seems to help tremendously, setting “squash” to “no mapping” is not the same; looks like you can’t achieve the wished purpose through the web GUI
Update 2015-01-26 / 0: /etc/idmap.conf – but the respective software on openSuSE seems to have problems.
Update 2015-01-26 / 1:
- no more UID squashing or mapping within the DSM GUI,
- no more changes to /etc/exports on the NAS “under the hood”,
- simple vanilla “Squash: No mapping” within the DSM GUI;
- ie. the respective UIDs on the NFS server and the NFS clients must match 1:1.
- It is quite simple to rectify this on the NFS clients.
- I have no idea, why I hesitated doing that from the beginning (when I started using the Synology devices as NFS servers).
- For the time being this is “the proper way” here.
- For the “better future” of course implementation of a Kerberos set-up is the way to go:
- https://en.wikipedia.org/wiki/Kerberos_(protocol)
- http://linux.die.net/man/5/exports – /etc/exports