How to keep group-writeable shares on Samba with OSX clients?
Posted
by
Oliver Salzburg
on Super User
See other posts from Super User
or by Oliver Salzburg
Published on 2013-11-14T17:04:02Z
Indexed on
2014/08/20
10:25 UTC
Read the original article
Hit count: 293
I have a FreeNAS server on a network with OSX and Windows clients. When the OSX clients interact with SMB/CIFS shares on the server, they are causing permission problems for all other clients.
Update: I can no longer verify any answers because we abandoned the project, but feel free to post any help for future visitors.
The details of this behavior seem to also be dependent on the version of OSX the client is running. For this question, let's assume a client running 10.8.2.
When I mount the CIFS share on an OSX client and create a new directory on it, the directory will be created with drwxr-x-rx
permissions. This is undesirable because it will not allow anyone but me to write to the directory. There are other users in my group which should have write permissions as well. This behavior happens even though the following settings are present in smb.conf
on the server:
[global]
create mask
= 0666
directory mask
= 0777
[share]
force directory mode
= 0775
force create mode
= 0660
I was under the impression that these settings should make sure that directories are at least created with rwxrwxr-x
permissions. But, I guess, that doesn't stop the client from changing the permissions after creating the directory.
When I create a folder on the same share from a Windows client, the new folder will have the desired access permissions (rwxrwxrwx
), so I'm currently assuming that the problem lies with the OSX client.
I guess this wouldn't be such an issue if you could easily change the permissions of the directories you've created, but you can't. When opening the directory info in Finder, I get the old "You have custom access" notice with no ability to make any changes.
I'm assuming that this is caused because we're using Windows ACLs on the share, but that's just a wild guess.
Changing the write permissions for the group through the terminal works fine, but this is unpractical for the deployment and unreasonable to expect from anyone to do.
This is the complete smb.conf
:
[global]
encrypt passwords = yes
dns proxy = no
strict locking = no
read raw = yes
write raw = yes
oplocks = yes
max xmit = 65535
deadtime = 15
display charset = LOCALE
max log size = 10
syslog only = yes
syslog = 1
load printers = no
printing = bsd
printcap name = /dev/null
disable spoolss = yes
smb passwd file = /var/etc/private/smbpasswd
private dir = /var/etc/private
getwd cache = yes
guest account = nobody
map to guest = Bad Password
obey pam restrictions = Yes
# NOTE: read smb.conf.
directory name cache size = 0
max protocol = SMB2
netbios name = freenas
workgroup = COMPANY
server string = FreeNAS Server
store dos attributes = yes
hostname lookups = yes
security = user
passdb backend = ldapsam:ldap://ldap.company.local
ldap admin dn = cn=admin,dc=company,dc=local
ldap suffix = dc=company,dc=local
ldap user suffix = ou=Users
ldap group suffix = ou=Groups
ldap machine suffix = ou=Computers
ldap ssl = off
ldap replication sleep = 1000
ldap passwd sync = yes
#ldap debug level = 1
#ldap debug threshold = 1
ldapsam:trusted = yes
idmap uid = 10000-39999
idmap gid = 10000-39999
create mask = 0666
directory mask = 0777
client ntlmv2 auth = yes
dos charset = CP437
unix charset = UTF-8
log level = 1
[share]
path = /mnt/zfs0
printable = no
veto files = /.snap/.windows/.zfs/
writeable = yes
browseable = yes
inherit owner = no
inherit permissions = no
vfs objects = zfsacl
guest ok = no
inherit acls = Yes
map archive = No
map readonly = no
nfs4:mode = special
nfs4:acedup = merge
nfs4:chown = yes
hide dot files
force directory mode = 0775
force create mode = 0660
© Super User or respective owner