ACLs problem maybe, for macOS smb share

[ieronymous]

Hi
I created a test dataset on a TrueNAS-SCALE-22.12.2 version, named Creativestoresmb which is a child of the ActiveDpool dataset. This will be shared via smb to macOS (Monterey version) clients for project storage usage. I have created a user natal and a group as well. I set the ACLs in a way that user natal is the owner of the Creativestoresmb dataset with read/write/execute permissions. At dataset's options / advanced the ACL Type is set to default POSIX.
Extra info

SMB Services->advanced->UNIX Charset: UTF-8
Enable Apple SMB2/3 Protocol Extensions is not checked if I m not mistaken, the benefits are for Time Machine support.

Share ACL for Creativestoresmb->Permission*: FULL
->Type: ALLOWED


Also automatically the ActiveDpool->Creativestoresmb dataset has automatically created a child dataset with the name of the user so it is
ActiveDpool->Creativestoresmb->natal

POSIX Permissions for natal dataset (auto-created) are:
User Obj – natal Read | Write | Execute
User – natal Read | Write | Execute
Group Obj – natal Read | Write | Execute
Group – natal Read | Write | Execute
Mask Read | Write | Execute
Other Read | Execute
User Obj – default – natal Read | Write | Execute
User – default – natal Read | Write | Execute
Group Obj – default – natal Read | Write | Execute
Group – default – natal Read | Write | Execute
Mask – default Other – default
Other – default Other – default

POSIX Permissions for Creativestoresmb dataset (parent of natal) are:
Permissions:
Owner: natal
Group: natal

Unix Permissions
person natal Read | Write | Execute
people natal Read | Write | Execute
groups Other Read | Execute


The issue is that when the user connects to the share and copies a project there, then it can modify the file names for instance but he can t modify name of folders though, Each time trying to change a folder's name, a credential window pops up asking for user/pass which she gives and an error message about wrong credentials is returned which is not the case. If I access the share from a Win client and try to change the name of the file it lets me.

Maybe permission issues.....

 

[ieronymous]

.......also some additional info (since I can t edit my initial post)

Edit SMB share
Purpose*: Private SMB Dataset and Shares (Maybe I need a different type for macOS environments)

Edit SMB share -> Advanced
Enable ACL: Checked
Access Based Share Enumeration: Checked

Edit SMB share -> Other Options
Use Apple-style Character Encoding: Chekced

 

[morganL]

.......also some additional info (since I can t edit my initial post)

Edit SMB share
Purpose*: Private SMB Dataset and Shares (Maybe I need a different type for macOS environments)

Edit SMB share -> Advanced
Enable ACL: Checked
Access Based Share Enumeration: Checked

Edit SMB share -> Other Options
Use Apple-style Character Encoding: Chekced

Can you also test from both a windows client and a MacOS client. We've been seeing different behaviour.

 

[ieronymous]

Can you also test from both a windows client and a MacOS client. We've been seeing different behaviour.

I have already done it and from Windows it seems to have the freedom to rename central folders. I tent to believe that because the original copy of that project came from the Mac environment with Monterey OS and M1 or M2 risk cpus (can t remember right now, after all I am not really into Macs but I just have to make it work for our designer department), they lock everything. They even have a protected area where you work and every time you try to change something it considers critical (even the rename of a folder) and pops up credential window. Thing is that it pops up security window as well from the nas side but whatever creds she enters it keeps failing. Also she sent me a print screen from Adobe designer, where she was trying to save a picture and got a message about disk error, which is not the case here.

I also recreated the dataset with smb type and let everything default. Same thing happened. User transferred the project to the shared location and after that, same behavior as with previous share.

 

[morganL]

I have already done it and from Windows it seems to have the freedom to rename central folders. I tent to believe that because the original copy of that project came from the Mac environment with Monterey OS and M1 or M2 risk cpus (can t remember right now, after all I am not really into Macs but I just have to make it work for our designer department), they lock everything. They even have a protected area where you work and every time you try to change something it considers critical (even the rename of a folder) and pops up credential window. Thing is that it pops up security window as well from the nas side but whatever creds she enters it keeps failing. Also she sent me a print screen from inside designer, where trying to save a picture got her an error message about disk error, which is not the case here.

I also recreated the dataset with smb type and let everything default. Same thing happened. User transferred teh project to the new location and after that same behavior as with previous share.

The challenge is that it's hard to declare this as a TruenAS issue if the windows client works....
If the MacOS client works on another NAS.. then there is some evidence that TrueNAS/Samba should behave differently.

 

[ieronymous]

The challenge is that it's hard to declare this as a TruenAS issue if the windows client works....
If the MacOS client works on another NAS.. then there is some evidence that TrueNAS/Samba should behave differently.

Well I have a confirmation on a friend of mine who administers mostly macOS devices, but the shares are created with a synology machine and as he mentions synology has a client with which macOS devices are connected with the shares.

On the other hand he didn t mention the version macOS devices are using and the files are created from scratch to that shared folder.

I ve read about broken implementation of smb with Ventura version of macOS but I don t know if that applies to Monterey as well. After all, Apple alone deprecated AFP protocol to favor smb. As it seems she doesn t favor it well though.

I have to try the share with another mac we have, having an older version of the OS (I think it is Sierra) and check the behavior after a project is being copied

 

[ieronymous]

Maybe I might have found something as an intermediate step to make it work, but I don t like the way it plays.
I created a user in macOS with the exact name and password used, in order to access the share (so that user exists in truenas as well).
-> Didn t play.

New edit: Even tried to create a user in TrueNAS side, with same credentials as that of the macOS user so to be identical. Same thing if you copy a folder inside the share can t rename it afterwards. Other times it lets you do it and if you close the folder and re-open the share it won t let you revert it back to it's original name.

Afterwards I went to folder in macOS and under permissions I added that created user, giving him read / write access. Only then and without even re-copying the file to the share storage (so used the one already there), gave him immediate access to rename the folder and make changes in Photoshop / indesign without giving him an error (and a specially silly one like that of <<can t save due to disk error>>)

Apart from that, if the user created the file / project inside shares storage no problem do whatever he wants, even transfer it to his machine make changes the back again to the storage without any problems.

Still, I feel I need to find a more global way of making it work.

PS Each step or at the end of the process, requires a restart at the macOS machine.

 

[ieronymous]

probably solved it. I t requires an addition step from the macOS client though. He can copy as many folders - files as he wants and afterward as I mentioned above, the problem was that he couldn t rename the top folders or move them,... etc. Well if he just disconnects the share and re-connects he is able to do all of the above actions. I can t quite get if this is a Truenas or macOs bug, but this way works. Tested it multiple times.

PS Win clients don t have that kind of problem and they don t require to disconnect the share after the copy process in order to be able to modify their data.

 

[morganL]

probably solved it. I t requires an addition step from the macOS client though. He can copy as many folders - files as he wants and afterward as I mentioned above, the problem was that he couldn t rename the top folders or move them,... etc. Well if he just disconnects the share and re-connects he is able to do all of the above actions. I can t quite get if this is a Truenas or macOs bug, but this way works. Tested it multiple times.

PS Win clients don t have that kind of problem and they don t require to disconnect the share after the copy process in order to be able to modify their data.

Thanks... I suspect its a MacOS issue if Windows clients don't have the issue, but useful to know.

If the MacOS clients worked well with another SMB server..... then I reserve the right to change my mind

 

[ieronymous]

If the acOS clients worked well with another SMB server..... then I reserve the right to change my mind

.... well as I mentioned above in one of my posts, in Synology I have confirmation that they work fine. I have to ask again if the share is using smb protocol or synology client which I don t know what exactly it is supposed to use as a protocol underneath.

 

[morganL]

Synology Drive Client... is a file syncing protocol, not an SMB file share protocol. Is that the reason?

 

[ieronymous]

Synology Drive Client... is a file syncing protocol, not an SMB file share protocol. Is that the reason?

I ll ask and know more tomorrow hopefully.