Description of problem: Not able to create symlinks when acl is enabled on the volume. Version-Release number of selected component (if applicable): nfs-ganesha-2.3.1-7 How reproducible: Always Steps to Reproduce: 1. Create a ganesha cluster and create a volume. 2. Export volume via ganesha and mount it using v4 on client 3. Set Disable_ACL=false in volume export file 4. Create a file on the mount point and try to create a symlink for that file and observe that it fails with file already exist. [root@dhcp37-206 nfs1]# ls [root@dhcp37-206 nfs1]# mkdir dir [root@dhcp37-206 nfs1]# touch file [root@dhcp37-206 nfs1]# ln -s /mnt/nfs1/file /mnt/nfs1/dir/file2 ln: failed to create symbolic link ‘/mnt/nfs1/dir/file2’: File exists 5. Also, the links which are created before setting Disable_ACL=false, gives stale file handle as below: When Disable_ACL=true: [root@dhcp37-206 nfs1]# ls [root@dhcp37-206 nfs1]# mkdir dir [root@dhcp37-206 nfs1]# touch file [root@dhcp37-206 nfs1]# ls dir file [root@dhcp37-206 nfs1]# ln -s /mnt/nfs1/file /mnt/nfs1/dir/file1 [root@dhcp37-206 nfs1]# ls dir file [root@dhcp37-206 nfs1]# cd dir/ [root@dhcp37-206 dir]# ls file1 [root@dhcp37-206 dir]# ls -ltr total 0 lrwxrwxrwx. 1 root root 14 Jun 7 01:16 file1 -> /mnt/nfs1/file When Disable_ACL is set to false, for the same link, we get "Stale file handle" [root@dhcp37-206 dir]# ls -ltr ls: cannot access file1: Stale file handle total 0 l????????? ? ? ? ? ? file1 Actual results: Not able to create symlinks when acl is enabled on the volume. Expected results: There should not be any failures while creating or accessing symlinks Additional info:
Upstream patch is merged now.
https://review.gerrithub.io/#/c/279330 . This patch talks about fising issue with dead links. Could you please explain why the creation of symlinks in case of valid files also fails and how this patch resolves it. Thanks!
(In reply to Soumya Koduri from comment #8) > https://review.gerrithub.io/#/c/279330 . This patch talks about fising issue > with dead links. Could you please explain why the creation of symlinks in Yes it works fine with normal links, but during testing we used absolute path of target instead of relative path, that ends ups similar scenario. In gluster perspective they are deadlinks > case of valid files also fails and how this patch resolves it. Thanks!
Verified this bug with latest ganesha-2.3.1-8 build and it works as expected. >>> All the symlinks created before acl is enabled doesn't give stale file handle now and show proper attributes: When ACL is disabled: [root@dhcp37-206 nfs1]# touch file1 [root@dhcp37-206 nfs1]# touch file2 [root@dhcp37-206 nfs1]# touch file3 [root@dhcp37-206 nfs1]# mkdir dir1 [root@dhcp37-206 nfs1]# mkdir dir2 [root@dhcp37-206 nfs1]# mkdir dir3 [root@dhcp37-206 nfs1]# mkdir dir4 [root@dhcp37-206 nfs1]# mkdir dir5 [root@dhcp37-206 nfs1]# mkdir dir6 [root@dhcp37-206 nfs1]# ls dir1 dir2 dir3 dir4 dir5 dir6 file1 file2 file3 [root@dhcp37-206 nfs1]# ln -s /mnt/nfs1/file1 /mnt/nfs1/dir4/file4 [root@dhcp37-206 nfs1]# ln -s /mnt/nfs1/file2 /mnt/nfs1/dir4/file5 [root@dhcp37-206 nfs1]# ln -s /mnt/nfs1/file3 /mnt/nfs1/dir4/file6 [root@dhcp37-206 nfs1]# cd dir4/ [root@dhcp37-206 dir4]# ls file4 file5 file6 [root@dhcp37-206 dir4]# ls -ltr total 0 lrwxrwxrwx. 1 root root 15 Jun 8 02:31 file4 -> /mnt/nfs1/file1 lrwxrwxrwx. 1 root root 15 Jun 8 02:31 file5 -> /mnt/nfs1/file2 lrwxrwxrwx. 1 root root 15 Jun 8 02:31 file6 -> /mnt/nfs1/file3 [root@dhcp37-206 dir4]# [root@dhcp37-206 nfs1]# ln -s /mnt/nfs1/dir1/ /mnt/nfs1/dir4/dir7 [root@dhcp37-206 nfs1]# ln -s /mnt/nfs1/dir2/ /mnt/nfs1/dir4/dir8 [root@dhcp37-206 nfs1]# ln -s /mnt/nfs1/dir3/ /mnt/nfs1/dir4/dir9 [root@dhcp37-206 nfs1]# cd dir4 [root@dhcp37-206 dir4]# ls -ltr total 0 lrwxrwxrwx. 1 root root 15 Jun 8 02:31 file4 -> /mnt/nfs1/file1 lrwxrwxrwx. 1 root root 15 Jun 8 02:31 file5 -> /mnt/nfs1/file2 lrwxrwxrwx. 1 root root 15 Jun 8 02:31 file6 -> /mnt/nfs1/file3 lrwxrwxrwx. 1 root root 15 Jun 8 02:32 dir7 -> /mnt/nfs1/dir1/ lrwxrwxrwx. 1 root root 15 Jun 8 02:32 dir8 -> /mnt/nfs1/dir2/ lrwxrwxrwx. 1 root root 15 Jun 8 02:33 dir9 -> /mnt/nfs1/dir3/ Enable Acl on the volume and check the symlinks for files and dirs: [root@dhcp37-206 dir4]# ls -ltr total 0 lrwxrwxrwx. 1 root root 15 Jun 8 02:31 file4 -> /mnt/nfs1/file1 lrwxrwxrwx. 1 root root 15 Jun 8 02:31 file5 -> /mnt/nfs1/file2 lrwxrwxrwx. 1 root root 15 Jun 8 02:31 file6 -> /mnt/nfs1/file3 lrwxrwxrwx. 1 root root 15 Jun 8 02:32 dir7 -> /mnt/nfs1/dir1/ lrwxrwxrwx. 1 root root 15 Jun 8 02:32 dir8 -> /mnt/nfs1/dir2/ lrwxrwxrwx. 1 root root 15 Jun 8 02:33 dir9 -> /mnt/nfs1/dir3/ As seen earlier, there is no “Stale file handle” error seen now and all the links are shown with correct attributes >>>> Also, when ACL is enabled, we are able to create symlinks without any issues: [root@dhcp37-206 nfs1]# touch file11 [root@dhcp37-206 nfs1]# touch file12 [root@dhcp37-206 nfs1]# touch file13 [root@dhcp37-206 nfs1]# ls dir1 dir2 dir3 dir4 dir5 dir6 file1 file11 file12 file13 file2 file3 [root@dhcp37-206 nfs1]# mkdir dir11 [root@dhcp37-206 nfs1]# ls dir1 dir11 dir2 dir3 dir4 dir5 dir6 file1 file11 file12 file13 file2 file3 [root@dhcp37-206 nfs1]# ln -s /mnt/nfs1/file11 /mnt/nfs1/dir5/file14 [root@dhcp37-206 nfs1]# ln -s /mnt/nfs1/file12 /mnt/nfs1/dir5/file15 [root@dhcp37-206 nfs1]# ln -s /mnt/nfs1/file13 /mnt/nfs1/dir5/file16 [root@dhcp37-206 nfs1]# ln -s /mnt/nfs1/dir1 /mnt/nfs1/dir5/dir21 [root@dhcp37-206 nfs1]# ln -s /mnt/nfs1/dir2 /mnt/nfs1/dir5/dir22 [root@dhcp37-206 nfs1]# ln -s /mnt/nfs1/dir3 /mnt/nfs1/dir5/dir23 Based on the above observation, marking this bug as Verified.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2016:1247