On 08/31/2015 08:24 PM, Brett Viren wrote:
> ~Stack~ <[log in to unmask]> writes:
> 
>> I have been pouring over this for an hour. I have asked 3 coworkers. I
>> can't figure it out. User3 isn't a part of any special group or anything.
> 
> By chance are you falling fowl to user info caching?  Adding a user to a
> group won't affect any sessions that were already started before the
> change.
> 
> Having each user run the "groups" command will tell the story.  Or just
> have them log out/in again.

Greetings!

I have checked caching and it isn't the issue.

I mentioned that the path is /data/share/share{123}. If I "rsync -avHlP"
the directories to /data/temp/, it works perfectly the way it should.
/data is a single partition volume on the same file system.

In fact, I created /data/testing/ and verified that all of the
permissions are working properly. I then 'mv /data/testing
/data/share/.' and those _exact_ permissions that were working, stop.
The exact same problem as the original folders.

Some thing some how is making the permissions in /data/share more
liberal and I am at a complete loss as to what it is. I am convinced it
is something on the file system but that is about as far as I have got.

SELinux isn't flagging anything. ACL's are not enabled. And every Linux
system I mount this partition on shows the exact same odd behavior once
I copy over the users/groups. It has to be something on the file system,
but I haven't ever seen anything like this that so blatantly refuses to
adhere to the Linux permissions.


Thanks for the suggestion though! I do appreciate it.

~Stack~