Comment conserver des partages en écriture de groupe sur Samba avec des clients OSX?


6

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-rxautorisations. 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.confsur 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-xautorisations. 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.

entrez la description de l'image ici

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

1
La [share]section aura priorité sur la [global]section lorsque deux options seront identiques
Canadian Luke du

Pouvez-vous poster le smb.conffichier entier ?
Canadien Luke

@CanadianLuke: Fait
Der Hochstapler

Avez-vous un accès SSH complet à votre FreeNAS? Pouvez-vous définir des autorisations de dossier sur le terminal?
Canadien Luke

@CanadianLuke: Oui, j'ai un accès SSH au serveur et la définition d'autorisations via le terminal ne pose aucun problème.
Der Hochstapler

Réponses:


3

Pour empêcher les clients OS X de modifier les autorisations, vous devez ajouter

unix extensions = no

à la section [Global] de votre smb.conf

Et / ou ajouter quelque chose comme

force security mode = 0660
force directory security mode = 02770

à vos définitions de partage pour préserver les droits d’écriture de groupe.


La seule solution de travail que j'ai pu trouver. Merci!
Antonio

Cette solution a également fonctionné pour moi. Les utilisateurs Windows / autorisations de groupe ont été correctement créés, mais lorsqu'un utilisateur mac crée un répertoire, il ne respecte pas les définitions de partage d'utilisateur définies, même s'il est forcé. Merci!
trail_runner

1

Modifiez vos définitions de partage pour ne contenir que les suivantes:

path = /path/to/folder
browseable = yes
writeable = yes
inherit permissions = yes

Maintenant, changez les permissions sur les dossiers directement:

# chown user:group -R /path/to/folder
# chmod 2770 -R /path/to/folder (or 2775 for public read only)

Des autorisations "spéciales" sont appliquées à la commande CHMOD ci-dessus, ce qui permet aux dossiers déposés dans le dossier de prendre automatiquement les autorisations du parent. Pour que cela prenne effet:

/etc/init.d/samba reload

Le reloadcommutateur ne redémarre pas samba (élimine les utilisateurs actuels), mais recharge le fichier de configuration.


De plus, documenté sur le Wiki FreeNAS :

Si les autorisations fonctionnent pour les utilisateurs Windows mais pas pour les utilisateurs OS X, essayez de désactiver les extensions Unix et de redémarrer le service CIFS.


0

Si vous créez ces dossiers dans Terminal.app, définissez peut-être le paramètre umask à l'échelle du système sur 002 (777 - umask = masque pour les exécutables et les dossiers 666 - umask = masque pour les fichiers) au lieu de 022, c'est une possibilité.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.