45 votes

Comment monter un partage CIFS via FSTAB et donner tous les droits à l'invité ?

Je souhaite créer un dossier public avec un accès RW complet. Le problème avec ma configuration est que les utilisateurs de Windows n'ont aucun problème en tant qu'invités (ils peuvent RW et Delete), mon client Ubuntu ne peut pas faire la même chose. Nous pouvons seulement écrire et lire, mais pas créer ou supprimer.

Voici le fichier smb.conf de mon serveur :

[global]
    workgroup = WORKGROUP
    netbios name = FILESERVER
    server string = TurnKey FileServer

    os level = 20
    security = user
    map to guest = Bad Password
    passdb backend = tdbsam
    null passwords = yes

    admin users = root
    encrypt passwords = true
    obey pam restrictions = yes
    pam password change = yes
    unix password sync = yes
    passwd program = /usr/bin/passwd %u
    passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .

    add user script = /usr/sbin/useradd -m '%u' -g users -G users
    delete user script = /usr/sbin/userdel -r '%u'
    add group script = /usr/sbin/groupadd '%g'
    delete group script = /usr/sbin/groupdel '%g'
    add user to group script = /usr/sbin/usermod -G '%g' '%u'

    guest account = nobody

    syslog = 0
    log file = /var/log/samba/samba.log
    max log size = 1000

    wins support = yes
    dns proxy = no

    socket options = TCP_NODELAY
    panic action = /usr/share/samba/panic-action %d

[homes]
    comment = Home Directory
    browseable = no
    read only = no
    valid users = %S

[storage]
    create mask = 0777
    directory mask = 0777
    browseable = yes
    comment = Public Share
    writeable = yes
    public = yes
    path = /srv/storage

L'entrée FSTAB suivante ne donne pas un accès R/W complet au partage.

//192.168.0.5/storage /media/myname/TK-Public/ cifs rw 0 0

Cela ne fonctionne pas non plus

//192.168.0.5/storage /media/myname/TK-Public/ cifs rw,guest,iocharset=utf8,file_mode=0777,dir_mode=0777,noperm 0 0

L'utilisation de l'emplacement suivant dans Nemo/Nautilus sans que le partage soit monté fonctionne :

smb://192.168.0.5/storage/

Info supplémentaire. Je viens de remarquer que si je copie un fichier sur le partage après l'avoir monté, mon client Ubuntu fait immédiatement de "nobody" le propriétaire, et le groupe "no group" a les droits de lecture et d'écriture, tous les autres étant en lecture seule.

enter image description here

Qu'est-ce que je fais de travers ?

80voto

Pauk Points 372

Il s'avère que je dois ajouter un UID local (client) à la ligne mount dans FSTAB pour que cela fonctionne. J'y suis arrivé par la force brute :

//192.168.0.5/storage /media/myname/TK-Public/ cifs guest,uid=myuser,iocharset=utf8,file_mode=0777,dir_mode=0777,noperm 0 0

8voto

Hugmeir Points 1239

Vous y êtes presque. Ouvrez FSTAB en utilisant :

sudo nano /etc/fstab

Dans la dernière ligne (ou l'une des dernières lignes), place :

//192.168.0.5/storage /media/myname/TK-Public/ cifs username=YOURUSERNAME,password=YOURPASSWORD,iocharset=utf8,file_mode=0777,dir_mode=0777

*** (il s'agit d'une seule et même ligne)

Ctrl - X pour fermer, Y pour sauvegarder et Enter pour conclure l'affaire.

Le redémarrage se fait maintenant par :

sudo reboot

Et vous devriez avoir le contrôle total du partage de réseau sur votre appareil Linux !

7voto

Alcamtar Points 484

CIFS n'a généralement pas de concept d'utilisateur et de groupe, de sorte que le montage d'un partage cifs montrera par défaut que l'utilisateur et le groupe sont "nobody" :

drwxdrwxdrwx. 3 nobody nobody 0 Sep 29 09:00 .
drwxdrwxdrwx. 9 nobody nobody 0 Sep 29 09:00 ..

Comme vous n'êtes pas "nobody", Linux ne vous laissera pas écrire sur quoi que ce soit qui n'ait pas la permission 0777, à moins que vous n'utilisiez sudo. Pour résoudre ce problème, ajoutez uid=mylogin,gid=mygroup à fstab et le partage apparaîtra comme s'il s'agissait de votre propre répertoire :

drwxdrwxdrwx. 3 mylogin mygroup 0 Sep 29 09:00 .
drwxdrwxdrwx. 9 mylogin mygroup 0 Sep 29 09:00 ..

Vous avez maintenant le contrôle total sans avoir besoin de sudo.

Cela ne change rien sur le serveur, puisque le serveur n'impose rien. Il dit à Linux de prétendre que vous êtes le propriétaire et de vous donner un accès illimité.

1voto

J'ai eu ce problème et c'est parce que l'utilisateur du partage n'en était pas propriétaire. J'ai corrigé le problème avec "sudo chown {username}:{groupname} /{share}/{path}" après quoi j'ai pu déplacer et supprimer des fichiers.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X