group permissions on directory being ignored for group member

[blind Pete]

Itamar Gal wrote:

> Hey Ubuntu users,
> 
> Some quick background about me. I'm a junior sysadmin in a firm whose IT
> department has no senior sysadmins, and I'm relatively new to the job.
> I've inherited an environment from a previous administrator who was much
> better at his job than I am, but who didn't leave much in the way of
> documentation.
> 
> Recently we've been experiencing a seemingly bizarre issue where it seems
> that there is a user (on an Ubuntu 12.04.4 server) who is unable to access
> a shared directory, even though that user belongs to the group which owns
> the directory. Here is an example session:
> 
> $ whoami
> username

Adam, Betty, Charlie, might be easier to read, 
or even user1, user2, group1, group2.  

> $ cd /shared_directory
> bash: cd: /shared_directory: Permission denied
> 
> ls /directory
> ls: cannot open directory /shared_directory: Permission denied
> 
> $ ls -ld /shared_directory
> drwxrws---+ 116 root groupname 4096 Jun 11 11:35 /shared_directory

Set group id when reading the directory? 
What does the plus mean?  ACL is involved?  
"man chmod" for as start, but I don't think it will tell you enough. 
"man attr" might help.  
 
There is a Gnome application called "Eiciel" for manipulating 
ACL's and extended user attributes, but I have not used it.

> $ getent group groupname
> groupname:*:username:otheruser
> 
> sudo adduser username groupname
> The user `username' is already a member of `groupname'
> 
> I posted this question on ServerFault here:
> 
> http://serverfault.com/questions/705988/group-permissions-on-directory-being-ignored-for-user
> 
> but I haven't gotten any responses.
> 
> A few remarks are probably in order. We are using LDAP-based
> authentication which inherits from a global LDAP server run outside of our
> department. We have a script which imports user data from the global LDAP
> server to our own LDAP server.
> 
> This permissions issue has happened a handful of times so far. Each time I
> was able to fix the problem by manually removing the user account form our
> LDAP server and then reimporting the account from the global server
> (although I have no idea why this had any effect, as I couldn't see any
> differences in the relevant LDAP entries). But now I've run into a case
> where doing this didn't resolve the problem, so I probably have to figure
> what's actually going on.
> 
> If anyone can shed any light on this I would be forever indebted to you,
> as I am completely baffled by this.
> 
> Cheers,
> Itamar
-- 
blind Pete
Sig goes here...