> I'm probably just reading too quickly, but I'm not seeing how this > explains the problems with your original configuration. > > Is it that /sr/nfs/bin on you system is a symlink? (And what exactly is > the content of that symlink?) No, all the directories under /srv/nfs are ordinary directories. The symlinks are in the root of the real file system. So I have: /bin -> /usr/bin /software -> /usr/lib (created to test the hypothesis) /srv/nfs/ /srv/nfs/assets /srv/nfs/bin /srv/nfs/software Because exportfs is not taking into account the rootdir setting, when it tries to resolve the path from /etc/exports, it sees the path /bin, and matches that with the real /bin, and resolves it to /usr/bin. Later exportfs errors when trying to resolve the real path (e_realpath) in the exportent_mkrealpath function, as this function does prepend the rootdir. This causes exportfs to look for /srv/nfs/usr/bin instead of the expected /srv/nfs/bin. At best this causes an error, but if that does happen to match an existing path under /srv/nfs then it would export the wrong directory. This will happen for any export that happens to match an existing symlink. There are two issues though that I'm not sure how best to handle: * Should the symlink be considered relative to the local system or relative to the rootdir? * What happens if the symlink points to a directory outside the rootdir? In my case I think the symlink would need to be resolved relative to the rootdir. This is because we're re-exporting an existing NFS server, so if the existing NFS server is exporting some kind of symlink tree, the symlinks would be relative to the existing mounts. One option that would be valid for my case would be an setting to disable symlink resolution and just consider it an error if an export is a symlink. Since I'm re-exporting an existing NFS server, they can't be symlinks anyway. -- Chris
