J'ai un serveur FreeNAS sur un réseau avec des clients OSX et Windows. Lorsque les clients OSX interagissent avec des partages SMB / CIFS sur le serveur, ils causent des problèmes d'autorisation pour tous les autres clients.
Mise à jour: je ne peux plus vérifier les réponses car nous avons abandonné le projet, mais n'hésitez pas à poster de l'aide pour les futurs visiteurs.
Les détails de ce comportement semblent également dépendre de la version d'OSX exécutée par le client. Pour cette question, supposons un client exécutant 10.8.2.
Lorsque je monte le partage CIFS sur un client OSX et que je crée un nouveau répertoire sur celui-ci, le répertoire est créé avec des drwxr-x-rx
autorisations. Ce n'est pas souhaitable car cela ne permettra à personne d'autre que moi d'écrire dans le répertoire. D'autres utilisateurs de mon groupe doivent également disposer d'autorisations en écriture. Ce problème se produit même si les paramètres suivants sont présents smb.conf
sur le serveur:
[global]
create mask
= 0666
directory mask
= 0777
[share]
force directory mode
= 0775
force create mode
= 0660
J'avais l'impression que ces paramètres devraient garantir que les répertoires sont au moins créés avec des rwxrwxr-x
autorisations. Mais, je suppose, cela n’empêche pas le client de modifier les autorisations après la création du répertoire.
Lorsque je crée un dossier sur le même partage à partir d'un client Windows, le nouveau dossier aura les autorisations d'accès souhaitées ( rwxrwxrwx
). Je suppose donc actuellement que le problème concerne le client OSX.
J'imagine que ce ne serait pas un problème si vous pouviez facilement modifier les autorisations des répertoires que vous avez créés, mais vous ne pouvez pas. Lorsque j'ouvre les informations sur le répertoire dans le Finder, l'ancien message "Vous avez un accès personnalisé" ne vous permet plus aucune modification.
Je suppose que cela est dû au fait que nous utilisons des listes de contrôle d'accès Windows sur le partage, mais ce n'est qu'une farce.
La modification des autorisations d'écriture pour le groupe via le terminal fonctionne bien, mais cela n'est ni pratique pour le déploiement ni trop raisonnable.
C'est la complète 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
smb.conf
fichier entier ?
[share]
section aura priorité sur la[global]
section lorsque deux options seront identiques