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~ <[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~
>