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