Description of problem: We are using the function to export all sub-directories in a gluster volume via nfs. For real directories it works fine but if we have a symbolic link which points to the directory, it is not possible to mount that directory via nfs and the name of the link. gluster volume on server: drwxr-xr-x 2 root root 6 Oct 22 14:24 folder lrwxrwxrwx 1 root root 7 Oct 22 14:24 link -> folder/ nfs mount on client: [root@gfs01 ~]# mount -t nfs -o vers=3 172.29.1.70:/gv0/link /nfs/ mount.nfs: an incorrect mount option was specified [root@gfs01 ~]# mount -t nfs -o vers=3 172.29.1.70:/gv0/folder /nfs/ [root@gfs01 ~]# Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. create and start a volume 2. create a directory in the volume 3. create a symbolic link to the directory in the volume 4. try to mount from client the sub-directory via nfs an the name of the link Actual results: mount.nfs: an incorrect mount option was specified Expected results: mount to be successful Additional info:
I reproduce the issue, In my opinion, the link only point a relative path, then the NFS client can not analysis the relative path. But in glusterfs server volume, can not create a absolute path symlink for the real sub directories.
It seems that the Linux kernel NFS-server allows mounting a symlink pointing to a directory. One requirement is that the target of the symlink points to a directory that is available on the export (I have not done any detailed permission checks).
This has been fixed with Bug 1157223 for Gluster 3.7. We can backport this change to glusterfs-3.6, but older versions would require quite some additional work. Backports to stable branches should keep the modifications relatively small, I do not think we should backport the change(s) to 3.4 or 3.5. Would you update to glusterfs-3.6 when we backport the change to that version?
Closing this bug now, there has been no response on comment #4. Please re-open this bug to request a backport.
This bug has been CLOSED, and there has not been a response to the requested NEEDINFO in more than 4 weeks. The NEEDINFO flag is now getting cleared so that our Bugzilla household is getting more in order.