I've seen some proprietary systems do weird stuff like make certain
users have UID 0 or be a member of group "root", you might want to check
those two things. I know it sounds silly, but that really does sound
like a strange UID 0 thing...
-Brad
On 08/31/2015 09:42 PM, ~Stack~ wrote:
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~
