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