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~