Cancel this issue. I found the problem. Explanation below...
We use active directory to manage our user accounts; however, open sssd doesn't seem to play well with gluster. When I turn it on, the cpu load shoots up to between 80-100% and stays there (previously submitted bug report). So, we I did on my gluster machines to keep the uid/gid updated (required due to server.manage-gids=on), is write a script that start opensssd, grabs all of the groups/users from the server, parses out the /etc/group and /etc/passwd file, and then shuts down sssd. I didn't realize that sssd uses the locally cached file. My script was running faster than sssd was updating the cache file, so this particular user wasn't in the SBIR group on all of the machines. He was in that group on gfs01a, but not on gfs01b (replica pair) or gfs02a/02b. I guess this gave him enough permission to cd into the directory, but for some strange reason he couldn't do an "ls" and have the directory name show up.
The only reason I do any of this is because I had to use server.manage-gids to overcome the 32-group limitation. This requires that my storage system have all of the user accounts and groups. The preferred option would be to simply use sssd on my storage systems, but it doesn't seem to play well with gluster.
David
------ Original Message ------
From: "David F. Robinson" <david.robinson@xxxxxxxxxxxxx>
To: "Gluster Devel" <gluster-devel@xxxxxxxxxxx>; "gluster-users@xxxxxxxxxxx" <gluster-users@xxxxxxxxxxx>
Sent: 2/3/2015 12:56:40 PM
Subject: gluster 3.6.2 ls issues
|
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel