Shared folder (SMB): Ownership, permissions + ACL

[strarsis]

Hi!

On macOS (Mac M1 hardware) I created a shared folder and let a device use it via SMB with its own user (e.g. "deviceuser").
The software on the device creates the folders and files with that user ("deviceuser") as sole owner and only the owner can read+write.

When the macOS admin user that created and shared that folder ("adminuser") tries to open directories or files created by the device,
a permission error occurs. The admin user first has to assign itself ownership or change the permissions (read everyone) of those folders and files (as root/sudo mode). This is very tedious.

Is it possible to force newly created folders or files to be owned also by the admin user or by a group to which the admin user and the device user both belong (with correct permissions)? I read that ACLs can be used to force this, I also tried a chmod-command to apply ownership/permissions inheritance, but this didn't change the behavior. Do I also have to enable ACLs in general?
Or is there another solution that also works?

Thanks and
with best regards

 

[Brian33]

I seems like ACLs (see 'man chmod') could do what you want with inheritance, but I don't understand them well enough at this point to tell you how.

I seem to remember that Tinkertool System has a gui/easier way to manipulate ACLs -- perhaps it would help. (I think it's a paid product, don't know if there's a trial version.)

You don't need to "enable ACLs" -- they are available by default. For example, my Documents directory has this ACL, apparently set when my user account was created:

0: group:everyone deny delete

I also tried a chmod-command to apply ownership/permissions inheritance, but this didn't change the behavior.

I'm curious what chmod command you tried...

 

[Brian33]

Regarding ACL inheritance, my testing indicates that the inherited access control entry (ACE) must be set on the top-level directory before the contained files/subdirectories are created. Files that already exist when the 'chmod' command is issued on the top-level directory don't get the new permissions (ACE) set on them. Only subsequently-created files get the new inherited ACE.

So, you'd have to start with an empty directory, set the inherited ACE on it. Only then have the "deviceuser" create all the files and subdirectories within it. Each of those items will then have the inherited ACE. (According to my very limited test.)

But with that caveat, the idea does seem to work, according to a simple test I did. Something like

deviceuser: mkdir top-dir
deviceuser: chmod +ai "adminuser allow list,add_file,search,add_subdirectory,delete_child,readattr,writeattr,file_inherit,directory_inherit" top-dir/

...then deviceuser fills the top-dir...
...now adminuser can list folders' contents and read the files!

Executing 'ls -le' on any of the files should show the inherited AC entry allowing adminuser to manipulate it.

I'm not sure what exact permissions you want to be included on the chmod command -- perhaps you don't want adminuser to be able to add_file, for example. If I were you I'd do some testing to be confident that the list covered everything 'adminuser' needs to do, without too much extra.

 

[strarsis]

Thanks for your testing and solution!

The device in question creates a folder for each day in that shared directory and inside the folder it puts files.
So your explanation indeed neatly explains what I have encountered: Despite having set the ACL (ACE or how it is called correctly) the further newly created files inside still hadn't have the correct ownership/permissions. But the folder that is created for the current day was already there - which is exactly the situation where applying the ACL would not work out of the box.

As this was already applied, it may well be that newly created folders for subsequent days (including) today are now already readable. I hadn't looked into this since then.

 

[strarsis]

I'm curious what chmod command you tried...

Today I was able to find the exact command I tried:

sudo chmod +a "group:my-share-group allow readsecurity,readattr,readextattr,list,search,read,execute,writeattr,
writeextattr,delete,add_file,add_subdirectory,delete_child,write,append,file_inherit,directory_inherit" ./shared-folder

To the group "my-share-group" belong the admin user and the device user.

 

[Brian33]

Today I was able to find the exact command I tried:

sudo chmod +a "group:my-share-group allow readsecurity,readattr,readextattr,list,search,read,execute,writeattr,
writeextattr,delete,add_file,add_subdirectory,delete_child,write,append,file_inherit,directory_inherit" ./shared-folder

Instead of chmod +a I think you need to use chmod +ai to create an ACE that you want to be inherited. Buried in the man page for chmod it says:

Inherited entries are added by using the +ai mode.

It looks like you got every type of permission I could think of, so that's good. I think it might have worked if you had used the +ai mode.

 

[strarsis]

@Brian33: Thanks. And yes, the newly created folders have been indeed accessible! So the modified command using `+ai` mode would have applied this not only to newly created folders but also to existing ones, then it would have worked out of the box with the already existing folder.
This is incredibly useful to know!

 

[Brian33]

Glad you had some positive results!

So the modified command using `+ai` mode would have applied this not only to newly created folders but also to existing ones

No, I don't think the '+ai' mode would apply to any existing folders. I don't see any way with 'chmod' to apply an ACE to existing, nested folders. (One could use the 'find' command with the '-exec' primary to do so, though it's a little bit complicated and would take some testing.)

I think the '+ai' is necessary to have any newly created folders inherit the ACE.