My beard is solid grey now, and I long recall using NFS for all these decades and here I cite the original RFC that gives us the basis for the NFS we have today RFC1094. Of course, three decades and some have passed since then, so here's the question:
In the interim has it become possible now, via a configuration option, to have links interpreted from the server side? This would surely clear up a number of my problems of client-side interpretation of links!
Or, am I all wet, and what I'm citing is obsolete and it's really, by default, resolving on the server side and I'm just chasing rabbits down rabbit-holes in my troubleshooting?
IF IT'S STILL OLD-SCHOOL AND INTERPRETED CLIENT SIDE, and if there is NOT an option that enables server-side interpretation, does using relative links instead of absolute ones possibly help?
Thanks.
Best Answer
The symlinks are always resolved by the client. There are several reasons for that. First of all, the NFS protocol has a concept of a file handle. Each handle points to a file system object that can be a directory, a file or a symlink (and some others). Moreover, NFSv4.1 spec is clearly says:
Second, by processing the symlink on the server side additional permission rules have to be taken into account, as symlink might point to outside on the exported filesystem.
Indeed, SAMBA servers have no option to follow symlinks. This is due to (a) original MS file systems didn't have a concept of a symlinks and (b) symbolic link as file system object type are added in SMB2. The behavior, BTW, matches NFS interpretation:
There are couple of user-space NFS server that allow custom file system implementations, if needed:
If there is a good reason to resolve symlinks on the server side, this can be added.