6

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.

Richard T
  • 1,206
  • 12
  • 29
  • Do you mean 1) the symlink client side appears as ... a symlink, the same, (thus it may go nowhere client side, if outside the NFS perimeter (esp. if absolute) eg in `/home/nfsserver/passwd -> /etc/passwd` the perimeter being `home/nfsserver`, and client side a `cat` of `passwd` would show the client passwd file ; or 2) the symlink client side is evaluated by the server when triggered, and will go to where the link points to server side, even if outside the perimeter allowed to client (client side a `cat` of `passwd` would show the server passwd file?) – Déjà vu Aug 29 '20 at 04:21
  • @e2-e4 I never considered your proposal. In my case, simply, I have a primary file server that has backup and the backup servers are supposed to be identical and take over in the case the primary fails. However, given how identical they are, the strategy to keep them current regarding backup has proven to not actually work since the links are interpreted on the client, not the server. ... I was aware of this but am not sure what the easiest way is to fix it. ... Hope this clarifies my particular case, but either way, it surely would be handy to have the ability to choose which side interprets. – Richard T Aug 29 '20 at 04:33
  • @e2-e4 It might be worth mentioning that in MY very specific use case, it might turn out that the best way is to simply use rsync without NFS. However, the site WAS using rsync, but between local and NFS mounted disks as a "local" transfer, and that was proven to not work; the local interpretation of the source was identical to the destination and so nothing happened! Oops! – Richard T Aug 29 '20 at 04:53
  • Not sure about your config (maybe you could add a graphical description in your question) but *rsync* is a smart beast and it detects when the files are/not the same (device ID, inodes ...). – Déjà vu Aug 29 '20 at 06:25
  • There is no way to tell server to resolve the symlinks on the server side. Moreover, such behavior can work, as symlink can point to a file or directly outside of exported path. Instead of solving this you better describe why it is required, as there might be a better way to achieve that. – kofemann Sep 05 '20 at 21:26
  • @kofemann If you're confident you are correct, that at present there is no way to have the server follow links for clients, then say so in an answer. Do note the present version of Samba on FC 32, 4.12.5, follows links for its clients and this behavior would be a handy option for NFS. Given nobody has suggested how this could be done with NFS, I've just "made adjustments" already by mandating a particular protocol to use for links. The deeper problem was that some people were using links without realizing they were being resolved on the client and reported bizarre behavior - they've adapted. – Richard T Sep 06 '20 at 00:24
  • 1
    Samba (SMB) works by path. NFS by file handles. – kofemann Sep 06 '20 at 06:58
  • @RichardT Finally got some time to write a complete answer. Let me know any update is needed. – kofemann Dec 12 '20 at 22:51
  • you could nfs export the location where the symlink points to. And if this is locally mounted under the same local location, the client symlink resolution will work. – bebbo Mar 16 '22 at 07:11

2 Answers2

4

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:

Whether created by an NFS client or created locally on the server, the data in a symbolic link is not interpreted when created, but is simply stored.

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:

Symbolic links MUST NOT be evaluated by the server.

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.

Stephan Samuel
  • 103
  • 3
kofemann
  • 4,626
  • 1
  • 25
  • 30
0

I have two computers on a network with the same NFS mount settings pointing to the server. On the server there are symlinks from one exported directory to another. On one client the links work just fine and on the other they are unreliable. I suspect that since the working client has a new version of NFS (same protocol use), a bug was fixed. In theory the request should go to the server and interpreted there since that is what is doing the exporting. If a client puts a symlink in the folder, then it will probably be broken on other clients. However, the server symlink should work. This general suggests that a special type of symlink for network shares is needed. Something like a server-symlink.

John Fro
  • 1