Description of problem: Version-Release number of selected component (if applicable): mainline How reproducible: if cache and hash subvolme of hardlink is different Steps to Reproduce: Run link/00.t test from posix testsuite(pjdtest suite) on nfs clients using ganesha Steps executed in script * create a file "abc" using root * create hardlink "link" for "abc" using a non root user, it fails with EACESS * delete "abc" * create directory "abc" using root * again try to create hadrlink "link" for "abc" using non root user, fails with ESTALE Actual results: Fails with ESTALE Expected results: Fail with EACESS Additional info: This is a similar issue fixed for rename in https://review.gluster.org/#/c/16016/ For hardlinks, if cached and hashed subvolumes are different, then it will first create linkto file in hashed using root permission, but actually hardlink creation fails with EACESS and stale linkto file is never removed. All the followup hardlink calls with file name will result ESTALE due to that linkto file. In the code mknod call for the linkto('T')[as part of dht_link] fails with EEXIST and following lookup results in ESTALE Thanks Susant for the help in RCAing above issue
The patch posted upstream for review https://review.gluster.org/#/c/17331/
downstream patch : https://code.engineering.redhat.com/gerrit/#/c/109763/
Verified this with build- # rpm -qa | grep ganesha nfs-ganesha-2.4.4-15.el7rhgs.x86_64 nfs-ganesha-gluster-2.4.4-15.el7rhgs.x86_64 glusterfs-ganesha-3.8.4-33.el7rhgs.x86_64 link/00.t test is passing.Hence moving this bug to verified state. home/new_posix/ntfs-3g-pjd-fstest/tests/link/00.t ....... ok /home/new_posix/ntfs-3g-pjd-fstest/tests/link/01.t ....... ok /home/new_posix/ntfs-3g-pjd-fstest/tests/link/02.t ....... ok /home/new_posix/ntfs-3g-pjd-fstest/tests/link/03.t ....... ok /home/new_posix/ntfs-3g-pjd-fstest/tests/link/04.t ....... ok /home/new_posix/ntfs-3g-pjd-fstest/tests/link/05.t ....... ok /home/new_posix/ntfs-3g-pjd-fstest/tests/link/06.t ....... ok /home/new_posix/ntfs-3g-pjd-fstest/tests/link/07.t ....... ok /home/new_posix/ntfs-3g-pjd-fstest/tests/link/08.t ....... ok /home/new_posix/ntfs-3g-pjd-fstest/tests/link/09.t ....... ok /home/new_posix/ntfs-3g-pjd-fstest/tests/link/10.t ....... ok /home/new_posix/ntfs-3g-pjd-fstest/tests/link/11.t ....... ok /home/new_posix/ntfs-3g-pjd-fstest/tests/link/12.t ....... ok /home/new_posix/ntfs-3g-pjd-fstest/tests/link/13.t ....... ok /home/new_posix/ntfs-3g-pjd-fstest/tests/link/14.t ....... ok /home/new_posix/ntfs-3g-pjd-fstest/tests/link/15.t ....... ok /home/new_posix/ntfs-3g-pjd-fstest/tests/link/16.t ....... ok /home/new_posix/ntfs-3g-pjd-fstest/tests/link/17.t ....... ok
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/RHBA-2017:2774