Bug 1343314 - Not able to create symlinks when acl is enabled on the volume.
Summary: Not able to create symlinks when acl is enabled on the volume.
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Gluster Storage
Classification: Red Hat
Component: nfs-ganesha
Version: rhgs-3.1
Hardware: x86_64
OS: Linux
unspecified
urgent
Target Milestone: ---
: RHGS 3.1.3
Assignee: Jiffin
QA Contact: Shashank Raj
URL:
Whiteboard:
Depends On:
Blocks: 1311817
TreeView+ depends on / blocked
 
Reported: 2016-06-07 06:37 UTC by Shashank Raj
Modified: 2016-11-08 03:52 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-06-23 05:33:57 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2016:1247 0 normal SHIPPED_LIVE nfs-ganesha update for Red Hat Gluster Storage 3.1 update 3 2016-06-23 09:12:43 UTC

Description Shashank Raj 2016-06-07 06:37:11 UTC
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:

Comment 3 Atin Mukherjee 2016-06-07 10:12:21 UTC
Upstream patch is merged now.

Comment 8 Soumya Koduri 2016-06-07 12:26:31 UTC
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!

Comment 9 Jiffin 2016-06-07 13:15:54 UTC
(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!

Comment 12 Shashank Raj 2016-06-08 08:54:47 UTC
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.

Comment 14 errata-xmlrpc 2016-06-23 05:33:57 UTC
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


Note You need to log in before you can comment on or make changes to this bug.