Target folder permissions NOT inheriting with MOVED files

[windnsalsa]

Hi, it has been exhausting researching and experimenting with permission settings to ultimately have files copied or moved to a "shared" folder to inherit permissions of their target parent folder. Below is an environment in my research.


Mac Pro [10.10.1 Yosemite] with a shared folder. PC [non Mac] as well as Mac clients using the same workgroup name accessing the shared folder. I have used the chmod ACL settings below. The permission inheritance works on NEWLY CREATED folders/files or COPIED [from locally or via a networked computer] folders/files. But, the inheritance does NOT work on folders/files that have been MOVED from same Mac or from another computer over the same network. Rather, these MOVED folders/files retain the permissions of their parent folder from where they were moved.


chmod -R +a "group:[examplegroup] allow list,add_file,search,add_subdirectory,delete_child,readattr,writeattr,readextat tr,writeextattr,readsecurity,file_inherit,directory_inherit" /path/to/folder


There will be times where folders/files will be MOVED rather than COPIED from various users and we want these files to also inherit permissions set on the target Shared folder. We don't want to manually configure the read+write permissions and "Apply to Enclose items" within the Get Info window.


This is a strange behavior when it comes to file sharing where read + write permissions are assumed within this group. I have tested this scenario on Windows 8 and 10 PCs and the shared folders there resulted in the desired permission inheritance as described above. What is Microsoft doing that Apple is not doing in this case?


Other things I have tried:

-Tinkertool System 2 application which resulted in the same undesired behavior.

-I have tested with a shared folder on a USB connected flash drive to represent an external hard drive and permissions do inherit as desired. But, we already have an external USB drive acting as a Time Machine backup. So, I don't want to connect 2 external drives in this scenario.


Possible solutions/workaround:

-I've heard that my desired permission inheritance might work on an OS X server version. I have not confirmed this to work. But I have not tried this. I don't want to have to upgrade or install a server OS on this Mac Pro just to have permissions to work. Also, the Mac Pro is being used as a desktop with 3rd party apps which I don't know would be restricted being used on OS X Server platform.

-NAS as a dedicated file server which might offer the desired inheritable permissions. I have not confirmed this. This would be an additional cost.


But the least costly and best solution for us would hopefully be to have the desired permissions inherited on the Mac Pro. We originally bought the Mac Pro to use it for day to day work as well as to serve as a file server for a very small office. Is there a way to get the desired inheritable permissions on moved folders/files? I have done extensive googling and most of the workarounds have been using the ACL chmod commands, but none of them addressed that it works on moved items. Please help.

 

[MacUser2525]

Did not read it all but the first paragraph or two. That is normal a new file which is what a move is to the operating system gets the permissions of the folder it goes into an already existing file keeps its existing settings. This is the way *nix permissions work at the system level nothing is going to change that, you could cobble together a script and a cron job to execute a change of permissions on the folders in question to keep them set the way you want.

 

[windnsalsa]

Did not read it all but the first paragraph or two. That is normal a new file which is what a move is to the operating system gets the permissions of the folder it goes into an already existing file keeps its existing settings. This is the way *nix permissions work at the system level nothing is going to change that, you could cobble together a script and a cron job to execute a change of permissions on the folders in question to keep them set the way you want.

Yes, I have been hearing about this behavior. But, it doesn't make good practical sense in a file sharing environment. Users should not be expected to have to always copy and never to move folders/files. What is being done in enviornment where *nix systems are being used as a file sharing servers [excluding NAS] to allow a desired behavior? This is where I am confused as well? I am wondering what is being done on the microsoft platform that allows this desired behavior?

 

[MacUser2525]

Yes, I have been hearing about this behavior. But, it doesn't make good practical sense in a file sharing environment. Users should not be expected to have to always copy and never to move folders/files. What is being done in enviornment where *nix systems are being used as a file sharing servers [excluding NAS] to allow a desired behavior? This is where I am confused as well? I am wondering what is being done on the microsoft platform that allows this desired behavior?

It makes perfect sense you want the files newly created to have their permissions set to the folder/user they are assigned to. Users are expected to be able to access the resources they are given they can move files about within those constraints. Now what you seem to want is some kind of contrary procedure with a to the system random set of permissions which you have not assigned to that folder. In a *nix environment you set up your permissions and live with it knowing its limitations which the administrator has set up. Windows I have no clue on it is going on twenty years since I have used that on any kind of regular basis. I am failing to see this desired behavior you speak of, does windows somehow allow arbitrary to the system setup permissions to occur?

 

[windnsalsa]

It makes perfect sense you want the files newly created to have their permissions set to the folder/user they are assigned to. Users are expected to be able to access the resources they are given they can move files about within those constraints. Now what you seem to want is some kind of contrary procedure with a to the system random set of permissions which you have not assigned to that folder. In a *nix environment you set up your permissions and live with it knowing its limitations which the administrator has set up. Windows I have no clue on it is going on twenty years since I have used that on any kind of regular basis. I am failing to see this desired behavior you speak of, does windows somehow allow arbitrary to the system setup permissions to occur?

To me and to most users who collablorate and share files within the same network, the following scenario would make sense.

Folder ShareParent [R+W with ACL inherit permissions down the file structure]:
-SubShareWrite folder [R+W inherited permissions from ShareParent]
-SubShareRead folder [ACL applied as (R)ead overriding the inherited permissions]

Either copied or moved file1 to SubShareWrite folder should AUTOMATICALLY inherit R+W permissions regardless of what permissions it was assigned previous to the copy/move. If that same file1 is transferred to the SubShareRead folder, then it's permission is Read. This is the desired behavior to facilitate file sharing. This is the result obtained from my tests on 2 PC computers [Windows 8 and 10]

Does this make sense to you?

 

[vexorg]

You could have a different partition, then format it FAT32, no permission problem then.

 

[MacUser2525]

To me and to most users who collablorate and share files within the same network, the following scenario would make sense.

Folder ShareParent [R+W with ACL inherit permissions down the file structure]:
-SubShareWrite folder [R+W inherited permissions from ShareParent]
-SubShareRead folder [ACL applied as (R)ead overriding the inherited permissions]

Either copied or moved file1 to SubShareWrite folder should AUTOMATICALLY inherit R+W permissions regardless of what permissions it was assigned previous to the copy/move. If that same file1 is transferred to the SubShareRead folder, then it's permission is Read. This is the desired behavior to facilitate file sharing. This is the result obtained from my tests on 2 PC computers [Windows 8 and 10]

Does this make sense to you?

Then chmod -R 0755 /path/to/shared/folder in a bash sctipt run from a cron job would likely take care of that or you could just ensure that every user is a member of the proper group(s) that have those permissions by default. Windows is no example to use everything as far as I remember on it is a 0777 file permission meaning everyone has read, write and execute permission by default that is how you get infected by a god damn email attachment a truly wonderful system.... You need to learn to do permissions properly.

 

[windnsalsa]

Then chmod -R 0755 /path/to/shared/folder in a bash sctipt run from a cron job would likely take care of that or you could just ensure that every user is a member of the proper group(s) that have those permissions by default. Windows is no example to use everything as far as I remember on it is a 0777 file permission meaning everyone has read, write and execute permission by default that is how you get infected by a god damn email attachment a truly wonderful system.... You need to learn to do permissions properly.

--I might have to try the chmod + cron job. Every 5 minutes or so would not be detrimental to performance or frequent disk writes, etc? So, is this a popular way to deal with this file sharing issue without using NAS or OS X SERVER in a typical small work environment? I feel it is an odd way to deal with such a standard service such as file sharing, which has been established a long time ago.

--As mentioned already, ensuring a group with appropriate permissions doesn't address the issue affecting only MOVED files

--Windows allow this automatic inheritance [Read or Write or whatever permissions specified]. Makes sense from a file sharing perspective. Malware is irrelevant to this topic.

 

[MacUser2525]

--I might have to try the chmod + cron job. Every 5 minutes or so would not be detrimental to performance or frequent disk writes, etc? So, is this a popular way to deal with this file sharing issue without using NAS or OS X SERVER in a typical small work environment? I feel it is an odd way to deal with such a standard service such as file sharing, which has been established a long time ago.

--As mentioned already, ensuring a group with appropriate permissions doesn't address the issue affecting only MOVED files

--Windows allow this automatic inheritance [Read or Write or whatever permissions specified]. Makes sense from a file sharing perspective. Malware is irrelevant to this topic.

No it most certainly not the proper way to do it, it is a down and dirty hack to get done what you want. Disk performance wise it should have no effect at all it is a simple file attribute modification taking milliseconds really to complete. The proper way as I have already mentioned it is to make sure that your users are the member of the correct group(s) such that the file when transferred has the correct settings already attached to it. There are decades of literature on doing this out there now OSX even though it is supposedly a certified UNIX does not do things the proper way either no case sensitivity, spaces in the god damn install name by default being a couple of my major pet peeves about it but you have to work with what you have. Even with those it is still by far the best *nix on the desktop by a county mile IMHO. And now I read my replies again perhaps a chown -R desired_owner:desired_group /path/to/shared/files would be in order as well if going the hack route.

 

[windnsalsa]

No it most certainly not the proper way to do it, it is a down and dirty hack to get done what you want. Disk performance wise it should have no effect at all it is a simple file attribute modification taking milliseconds really to complete. The proper way as I have already mentioned it is to make sure that your users are the member of the correct group(s) such that the file when transferred has the correct settings already attached to it. There are decades of literature on doing this out there now OSX even though it is supposedly a certified UNIX does not do things the proper way either no case sensitivity, spaces in the god damn install name by default being a couple of my major pet peeves about it but you have to work with what you have. Even with those it is still by far the best *nix on the desktop by a county mile IMHO. And now I read my replies again perhaps a chown -R desired_owner:desired_group /path/to/shared/files would be in order as well if going the hack route.

Yea, it seems like a hack to me.

Regarding the correct groups, that might work in a very structured and strict domain [e.g. Active Directory domain] where users would create or copy files. Moving files might result in something else. That's the crux of the issue I have encountered using on at least a non-server OS.

It might also work in a scenario within a very small workgroup [not domain] where each machine would have to have the exact same usernames and passwords of all the users who intend to participate in file sharing. This won't happen and is a nightmare to manage. Even then, MOVED files might not result in the desired way.

I am just disappointed in finding out about this behavior. Thanks for your time though. I wish more people would give their experiences.