On 08/31/2015 08:24 PM, Brett Viren wrote: > ~Stack~ <[email protected]> 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~
signature.asc
Description: OpenPGP digital signature
