Forum Linux.débutant Partage NFS et droits

Posté par  . Licence CC By‑SA.
Étiquettes :
0
19
août
2021

Bonjour,

Je sollicite votre aide car j'essaie de mettre en place une solution à base de NFS pour faire communiquer deux ordinateurs mais je me heurte à un problème de droits que je n'arrive pas à résoudre malgré un épluchage en règle des diverses doc' en ligne.

Contexte

Deux ordinateurs (GNU/Linux powered) reliés en ethernet sur un réseau local derrière une box.
- Le premier (appelons-le HTPC) n'a qu'un utilisateur et une partition tierce contenu des données multimédia est montée automatiquement au démarrage (c'est à cette partition qu'on veut accéder).
- Le deuxième (appelons-le desktop) a deux utilisateurs (toto et tata) qui va chercher à accéder aux données sur la partition tierce de HTPC (en mode lecture uniquement)

NFS

J'ai mis en place NFS côté serveur et côté client en accord avec la doc' :

Coté serveur

Je paramètre le fichier exports :
# nano /etc/exports

/mnt/1oc/eb37-5x91-47a9-989d-9zd7fd9q87rg/ 192.168.1.60/20(ro,sync,no_root_squash)

Dans cette ligne :
- /mnt/[…] : c'est le point de montage de la partition contenant des données multimédia dans le HTPC.
- 192.168.1.60/20 : c'est l'IP locale de desktop. (Je ne sais pas à quoi correspond le "/20", si on pouvait m'expliquer ?)
- (ro,sync,no_root_squash) : le "ro" est volontaire, la suite c'est des incantations tirées de divers tutos que je ne comprends pas très précisément.

Ensuite j'active le tout :
# exportfs -rav

Puis j'active le service :
# systemctl start nfs-server.service
# systemctl enable nfs-server.service
# systemctl start nfs-server.service

Et je perce mon pare-feu pour laisser passer les requêtes :
# firewall-cmd --permanent --add-service=nfs
# firewall-cmd --permanent --add-service=rpc-bind
# systemctl reload firewalld.service

Déjà là, y'a-t-il des fautes/erreurs à corriger ?

Côté client

Je crée le dossier qui servira de point de montage :
# mkdir /media/htpc

Et je monte le tout pour tester :
# mount -t nfs4 192.168.1.50:/mnt/1oc/eb37-5x91-47a9-989d-9zd7fd9q87rg/ /media/htpc

Et la ça marche ! \o/

J'en profite pour automatiser le montage au démarrage via cette ligne dans le fichier fstab :
192.168.1.50:/mnt/1oc/eb37-5x91-47a9-989d-9zd7fd9q87rg/ /media/htpc nfs auto,user,nofail,soft,retrans=2,timeo=5 0 0

Et là ça marche encore !

Le problème

En redémarrant le desktop, l'utilisateur toto peut facilement accéder au contenu distant (en lecture uniquement, comme prévu). Mais lorsque tata tente d'accéder au dossier distant, le navigateur de fichier renvoie un message d'erreur : tata n'a pas les droits pour accéder au dossier…

Je ne comprends pas d'où vient le problème car la connexion marche pour toto.
- Dans le fichier fstab, j'ai bien précisé l'option "user" qui, si je ne m'abuse, donne le droit à tous les utilisateurs de monter cette partition.
- Je n'ai pas donné moins de droits à tata ou plus de droits à toto donc je ne comprends pas d’où vient le problème.
- les commandes ont été lancées depuis le compte root donc ce n'est pas toto qui a lancé les commandes ni crée les dossiers (pourtant il apparait comme propriétaire de /media/htpc ?)
- j'ai essayé de changer les droits du point de montage /media/htpc sur desktop mais on me dit que je n'ai pas le droit d'écrire…

D'où ma question : comment faire ne sorte que toto comme tata puisse accéder au dossier distant ? Qu'ai-je omis dans ma configuration ?

Merci d'avance pour votre aide.

  • # droit coté serveur

    Posté par  . Évalué à 4.

    sur ton serveur tu as un seul utilisateur (UID = 1000)
    sur ton client, tu as 2 utilisateurs (UID=1000 et 1001)

    sur le serveur le disque partagé, n'est probablement autorisé que pour l'utilisateur 1000
    du coup l'utilisateur 1001 se fait refouler.

    • [^] # Re: droit coté serveur

      Posté par  . Évalué à 1.

      Merci neox pour cette réponse. Que me préconises-tu comme solution ?
      Je me noie un peu au milieu de toutes les options et leurs subtilités…

      • [^] # Re: droit coté serveur

        Posté par  . Évalué à 2.

        et bien de changer les droits sur le disque/dossier que tu veux partager depuis la machine qui fait serveur, pour autoriser tout le monde à lire.ecrire.modifier dessus.

        le plus simple
        en ligne de commande sur le serveur chmod 777 /chemin/dossier/partagé -R

        sinon creer ton 2e utilisateur sur le serveur aussi.
        verifier sur le PC son UID et faire le meme sur le serveur.

        puis mettre les 2 utilisateurs dans un seul groupe (partageNFS par exemple)
        puis sur le serveur autoriser le groupe partageNFS à lire/ecrire dans le disque/dossier

        chown :partageNFS /chemin/dossier/partagé -R
        chmod 2775 /chemin/dossier/partagé
  • # j'ai relu la question

    Posté par  . Évalué à 2. Dernière modification le 23 août 2021 à 09:36.

    J'en profite pour automatiser le montage au démarrage via cette ligne dans le fichier fstab :
    192.168.1.50:/mnt/1oc/eb37-5x91-47a9-989d-9zd7fd9q87rg/ /media/htpc nfs auto,user,nofail,soft,retrans=2,timeo=5 0 0

    Et là ça marche encore !

    Le problème

    En redémarrant le desktop, l'utilisateur toto peut facilement accéder au contenu distant (en lecture uniquement, comme prévu). Mais lorsque tata tente d'accéder au dossier distant, le navigateur de fichier renvoie un message d'erreur : tata n'a pas les droits pour accéder au dossier…

    Je ne comprends pas d'où vient le problème car la connexion marche pour toto.
    - Dans le fichier fstab, j'ai bien précisé l'option "user" qui, si je ne m'abuse, donne le droit à tous les utilisateurs de monter cette partition.

    justement, toto ayant monté la partition, elle lui appartient, donc tata ne peut pas y accéder

    enleve le user pour que ce soit le systeme qui monte la partition
    ajoute _netdev pour que cela attende que le reseau soit actif avant de monter la partition

    ainsi c'est root qui monte la partition distante indépendamment des interfaces graphiques

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.