Permission problem on public shares (18-2)

[picov]

There is a problem with permission.
I'm unable to copy folders into the public share: the folder is created but there is no right to write files inside.

In addition the the folders created at first level of the share can't be renamed (using both the guest access or an user account)

The folder is being created with the following permission:
drwxr-xr-x 2 nobody nobody 4096 2021-11-14 07:51 folder name

a chmod 777 solve the problem but only with existing folders.

[Jocko]

In addition the the folders created at first level of the share can't be renamed (using both the guest access or an user account)

Yes these folders (1xxx) can't be managed by the user. They are the mount point of the data partitions. Their permissions must not also be changed (775 and root/sys), this to prevent to overload the fw partition if the data partition is not mounted or the user set a bad location for downloading with transmission.
But what did you mean about "using both the guest access or an user account"

The folder is being created with the following permission:
drwxr-xr-x 2 nobody nobody 4096 2021-11-14 07:51 folder name

a chmod 777 solve the problem but only with existing folders.

This is not the regular behaviour, it should be created with permissions "777 root/root" and I just checked again this point by trying it.

Please to note if you create a folder from a shell access, indeed its permissions are 755

[picov]

I'm referring to the folders at first level INSIDE the share folder (users created folders).

I've tried to connect to a public share with guest and with an NAS user account and the behavior is the same: can't copy a folder with files inside to the NAS. Single file copy at the first level INSIDE the share works.

UPDATE 1:
I've verified that is a problem with samba configuration. If i connect to the same public share using AFP (netatalk) the problem not occurs.

However, using AFP I'm unable to connect with guest account: the error message say that the server software version is not supported (I'm using macOS Big Sur 11.6.1). No problem with AFP if I use an user account on the NAS.

Note: I'm using Samba4.10.18-patched

[Jocko]

I'm referring to the folders at first level INSIDE the share folder (users created folders).

I've tried to connect to a public share with guest and with an NAS user account and the behavior is the same: can't copy a folder with files inside to the NAS. Single file copy at the first level INSIDE the share works.

Ok so to answer about a former issue. yes you can rename "the folders created at first level of the share" : use the rename button when you edit the related share from the fw GUI

UPDATE 1:
I've verified that is a problem with samba configuration. If i connect to the same public share using AFP (netatalk) the problem not occurs.

Nope it works pecfectly on my side. I just created a public share "PermissionTry" and I can create a subfolder from a samba access with the right permissions:

Code: Select all

root@KAPPA:/share/1000 # ls -al PermissionsTry
total 12
drwxrwxrwx   3 root  root  4096 2021-11-14 10:10 .
drwxrwxr-x  30 root  sys   4096 2021-11-14 10:08 ..
drwxrwxrwx   2 Jocko Jocko 4096 2021-11-14 10:10 folder1


Note: the owner/group is Jocko because used previously this user account to get access on another private share. Otherwise owner/group would be nobody/nobody on an unprotected public share.

So my opinion the issue is on the laptop side and not on the nas side

Note: as your are ussing a MacOS, I got to make a test with my virtual bigsur host

[picov]

So my opinion the issue is on the laptop side and not on the nas side

I've switched to use native samba version (3.0.37). This cause the macOS connect with old smb version (getting info on shared folder the Format SMB is reported as "other" while with samba4 server the format is reported as "OSX").
With this version the problem not occurs.

I've, also tested that with a Win10 virtual machine the problem not occurs with both samba 3 or 4.

The samba4 performance are better than 3 (with samba 4 the speed match the netatalk afp server).

Could a tweak into smb.conf solve this problem ?

[Jocko]

Yes I confirm the issue is with MacOS (at least with bigSur and 10.xx ???) and samba4 and I could reproduce your issue.

It seems an additional umask is used by MacOS (022) and then :
- on a public share, permissions are 755 with owner 'nobody'
- on a private share, permissions are 755 with owner 'user' of the used account

So a bad behaviour for a nas server.

Could a tweak into smb.conf solve this problem ?

I need to check that but on the samba server the directive 'mask' is already set to set permissions 777 on a new folder and 666 on a file.

So need to make some Internet searches

[Jocko]

So currently the issue is only on a new folder and all is right on a new file

I did not find a directive to force permissions on the folder, the relative directive seems to have not effect :scratch

[picov]

How can I restart samba from shell with this linux distro ?

Some params to test:
https://wiki.samba.org/index.php/Config ... h_Mac_OS_X

[Jocko]

Yes I know this page for a long time now and the supported directives with our fw are already set in smb.conf ;)

You have to do it manually

Code: Select all

killall smbd
/usr/sbin/smbd -D -l /var/log/samba

[Jocko]

This issue is at least described here : https://unix.stackexchange.com/questions/486919/creating-a-directory-in-samba-share-from-osx-client-always-has-acl-maskr-x
but the fix does not work.

Anyhow we have to deep on vfs objects because these ones are used by apple OS and not by windows which would explain we do not have the same behaviour between apple and windows clients