Entry representing symlinks in .glusterfs is pointing to invalid entry. So acl fetch for symlinks will fail, correspondingly then all the fops(rm, ls) which requires a acl fetch will fail.
More detailed explaination of above comment. The .glusterfs folder will create links for all the entries inside the brick as gfid as its path, for directories it is a symlink and regular files as hardlinks. for example consider a volume "test" mounted at "/mnt", # gluster v i Volume Name: test Type: Distribute Volume ID: 5cc15dca-9e4c-45ea-913e-f5c26a0c1e7c Status: Started Number of Bricks: 1 Transport-type: tcp Bricks: Brick1: 10.0.0.7:/brick/b1 Options Reconfigured: performance.readdir-ahead: on #mount 10.0.0.7:/test on /mnt type fuse.glusterfs #cd /mnt create a directory "dir" in the mount #mkdir dir So at the backend in .glusterfs folder a hardlink is created for "dir" lrwxrwxrwx 1 root root 52 Jun 24 22:47 f9/ad/f9ad702b-5ef3-40ba-9d04-54b29b266255 -> ../../00/00/00000000-0000-0000-0000-000000000001/dir similar if a file named "foo" is created #touch foo in .glusterfs a hardlink created with path "93/8d/938d5b50-1457-4abb-a425-fbcbfed1c442" but for a symlinks #ln -s dir/ link in .glusterfs a symlink is created like this lrwxrwxrwx 2 root root 4 Jun 24 23:05 c7/ce/c7cea018-84c1-4c0b-954d-418c26a3a08d -> dir/ which is pointing to invalid context in .glusterfs (dead link) These links are cretated in .glusterfs using standard c libary function symlink() for directories and linkat() / link() for other files. In the current implementation of acl in posix xlator, uses standard libacl functions such as acl_get_file() / acl_set_file() . This link is given as input for them and when those functions tries to resolve it, will result in a "ENOENT" . So all the fops(like ls, rm etc) which requires fecthing acl for that symlink will fail.
Merged https://code.engineering.redhat.com/gerrit/51750
verified as can be seen, drwxr-xr-x. 7 acl_user1 acl_group 276 Jul 14 2015 acl_user1_dir8 lrwxrwxrwx. 1 root root 14 Jul 14 2015 dir5_symlink -> acl_user1_dir5
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://rhn.redhat.com/errata/RHSA-2015-1495.html