The permissions are set on the server and are 100% dependent on ACL.
You have two options in order to attempt to solve your issue.
1st option (which may better suit your needs): try to map/match Windows and Unix ACLs.
Edit the SMB server's
smb.conf file and add these parameters to the
nt acl support = yes
acl map full control = no
The two parameters above will cause the SMB server to attempt to map/match Windows and Unix ACLs.
nt acl support (S)
This boolean parameter controls whether smbd(8) will attempt to map
UNIX permissions into Windows NT access control lists. The UNIX
permissions considered are the traditional UNIX owner and group
permissions, as well as POSIX ACLs set on any files or directories.
acl map full control (S)
This boolean parameter controls whether smbd(8) maps a POSIX ACE
entry of "rwx" (read/write/execute), the maximum allowed POSIX
permission set, into a Windows ACL of "FULL CONTROL". If this
parameter is set to true any POSIX ACE entry of "rwx" will be
returned in a Windows ACL as "FULL CONTROL", is this parameter is
set to false any POSIX ACE entry of "rwx" will be returned as the
specific Windows ACL bits representing read, write and execute.
2nd option (workaround): set specific ACLs for each one of your shares.
In a nutshell, the RWX (read, write and execute) parameters are defined by these equivalent SMB parameters:
writeable = no is equivalent to R (read only)
writeable = yes is equivalent to RW (read and write)
acl allow execute always = true or
acl allow execute always = yes is equivalent to X (execute)
In order to set file/folder permissions for all your shares, it's necessary to edit the server's
smb.conf file and then add this global setting:
acl allow execute always = false
guest ok = no
writeable = yes
available = yes
browseable = yes
printable = no
locking = yes
...which will by default force all your shared folders to forbid execution of files (
acl allow execute always = false), forbid guest access (
guest ok = no), allow read and edit/(re)write access to files and folders (
writeable = yes), make all your shares available for use by the remote (client) users (
available = yes) and make the available shares visible (
browseable = yes), forbid using your shares as a printing spool directory (
printable = no), and force locking of your shares if the client sends such request to the SMB server (
locking = yes).
acl allow execute always (S)
This boolean parameter controls the behaviour of smbd(8) when
receiving a protocol request of "open for execution" from a Windows
client. With Samba 3.6 and older, the execution right in the ACL
was not checked, so a client could execute a file even if it did
not have execute rights on the file. In Samba 4.0, this has been
fixed, so that by default, i.e. when this parameter is set to
"False", "open for execution" is now denied when execution
permissions are not present.
If this parameter is set to "True", Samba does not check execute
permissions on "open for execution", thus re-establishing the
behaviour of Samba 3.6. This can be useful to smoothen upgrades
from older Samba versions to 4.0 and newer. This setting is not
meant to be used as a permanent setting, but as a temporary relief:
It is recommended to fix the permissions in the ACLs and reset this
parameter to the default after a certain transition period.
acl allow execute always = false doesn't work, try
acl allow execute always = no.
guest ok (S)
If this parameter is yes for a service, then no password is
required to connect to the service. Privileges will be those of the
This parameter nullifies the benefits of setting restrict anonymous
See the section below on security for more information about this
Inverted synonym for read only.
read only (S)
An inverted synonym is writeable.
If this parameter is yes, then users of a service may not create or
modify files in the service's directory.
Note that a printable service (printable = yes) will ALWAYS allow
writing to the directory (user privileges permitting), but only via
This parameter lets you "turn off" a service. If available = no,
then ALL attempts to connect to the service will fail. Such
failures are logged.
This controls whether this share is seen in the list of available
shares in a net view and in the browse list.
If this parameter is yes, then clients may open, write to and
submit spool files on the directory specified for the service.
Note that a printable service will ALWAYS allow writing to the
service path (user privileges permitting) via the spooling of print
data. The read only parameter controls only non-printing access to
This controls whether or not locking will be performed by the
server in response to lock requests from the client.
If locking = no, all lock and unlock requests will appear to
succeed and all lock queries will report that the file in question
is available for locking.
If locking = yes, real locking will be performed by the server.
This option may be useful for read-only filesystems which may not
need locking (such as CDROM drives), although setting this
parameter of no is not really recommended even in this case.
Be careful about disabling locking either globally or in a specific
service, as lack of locking may result in data corruption. You
should never need to set this parameter.