[RESOLU] Problème d'accès en RW à un lecteur réseau pour tous les uti.

jimbou · Le 30/01/2024, à 11:49

Bonjour,

J'ai une installation d'Ubuntu avec 2 utlisateurs : le principal qui a les droits root dans je fais un sudo, et un secondaire qui est simple utilisateur, avec un sudo limité.

Je monte un lecteur réseau par fstab:

//192.168.1.202/Master/ /mnt/Master cifs rw,user,users,noatime,_netdev,username=utilisateur,password=mot_de_passe 0 0

Mais ca ne donne les droits en écriture qu'à l'utilisateur principal. L'utlisateur secondaire n'a les droits qu'en lecture.

Comment je peux y remédier ? Je veux que tous les utlisateurs de l'appareil aient les droits en RW.

J'ai fait un chmod 777 sur /mnt/Master avant montage du lecteur réseau, mais après montage les droits changent et passent en RW pour le propriétaire (root) et R pour tous les autres.

D'avance merci.

Dernière modification par jimbou (Le 31/01/2024, à 15:10)

jplemoine · Le 30/01/2024, à 12:07

Je pense (mais à tester) qu'il faut ajouter le paramètre noauto.
Cela va permettre un "prémontage" mais c'est l'utilisateur qui fera la commande et qui aura les droits rw.
En graphique, il suffit de double-cliquer sur le répertoire dans l'explorateur de fichier (la ligne dans le fstab permet qu'il appraraisse en "grisé").

jimbou · Le 30/01/2024, à 14:47

Bonjour JPLemoine,

Ca marche avec un lecteur réseau en NTFS sous Windows. Je viens de le tester.

Mais quand je l'ai testé ce matin, c'était pour connecter un lecteur réseau ext4 sous linux, et ça ne marchait pas : en cliquant sur le répertoire, il était vide (ce qui veut dire que le lecteur réseau ne se montait pas). Mais bon, je réessaierai quand je serai à nouveau face à ce PC.

Et d'après ce que j'ai vu sur un forum, définir une option UID ou GID ne va pas aider pour un lecteur ext4.

Une solution, c'est de monter le lecteur à l'ouverture de la session, et le démonter à la fermeture. Mais est-ce que ça va marcher si je bascule entre des sessions déjà ouvertes ?

jplemoine · Le 30/01/2024, à 15:19

il faut peut-être regarder en montant manuellement en ligne de commande et/ou s'i n'y a pas une information dans les log.
Si c'est entre Linux et/ou un Windows récent, voir s'il n'est pas plus judicieux d'utiliser NFS.
A voir si le Windows comporte d'un client NFS.

jimbou · Le 30/01/2024, à 20:38

En fait, je veux que ça marche entre ordinateurs linux. J'ai fait des tests avec un lecteur réseau windows parce que je n'ai qu'un seul PC Linux chez moi, les autres sont Windows.

Pour monter sous linux un lecteur réseau Windows, j'ai trouvé la solution suivante, qui ne répond pas à 100 % mais presque: pour chaque utilisateur, je mets dans le fichier .profile deux lignes à la fin :

umount /mnt/Master
mount /mnt/master

Comme le montage se fait avec les options user et users, n'importe qui peut démonter le lecteur. Lorsqu'un utilisateur ouvre une session, il démonte le lecteur et le remonte sous son nom, et donc en RW.

Ca ne marche pas si je bascule entre deux sessions déjà ouvertes : le volume reste monté par la dernière des deux session qui a été ouverte. Mais ce n'est pas un cas d'utilisation significatif.

Je reste quand même surpris de ne pas pouvoir monter un volume en RW pour tout le monde.

jplemoine · Le 30/01/2024, à 20:56

Passe en NFS : de mémoire, on peut définir les droits comme on veut.

jimbou · Le 31/01/2024, à 09:07

Merci jplemoine d'avoir insisté sur NFS, j'avais lu un peu trop vite NTFS dans ton post précédent.

Malheureusement, ça ne marche pas. Que j'essaye de monter un volume réseau qui est sur windows ou qui est sur un autre Linux, voilà ce que j'obtiens:

jeannot@jeannot-asus-ubuntu:/media$ mount raspberry/
mount.nfs: remote share not in 'host:dir' format
jeannot@jeannot-asus-ubuntu:/media$

Voilà l'entrée fstab:

//192.168.1.24/Domoticz /media/raspberry nfs rw,username=utilisateur,password=mot_de_passe,user,users,noauto 0 0

En ajoutant : avant ou après ou à la place du /, ce qui pourrait correspondre à host:dir, par exemple comme ça,

//192.168.1.24:/Domoticz /media/raspberry nfs rw,username=utilisateur,password=mot_de_passe,user,users,noauto 0 0

j'ai une autre erreur:

mount.nfs: Failed to resolve server //192.168.1.24: Name or service not known

En cherchant sur Internet, je ne trouve rien d'utile sur cette erreur. Les causes ont l'air très disparates.

Si quelqu'un a une idée .....

Dernière modification par jimbou (Le 31/01/2024, à 09:20)

jimbou · Le 31/01/2024, à 09:59

Je suis émerveillé : c'est un problème de syntaxe.

Avec CIFS, il faut définir l'hote comme : //192.168.1.24/répertoire
Et avec NFS, ça doit être : 192.168.1.24:/répertoire

Mais ce n'est pas tout. Avec NFS, les options que j'ai définies pour CIFS génèrent une erreur. Alors je tatonne, pour trouver quelles sont les options qui fachent NFS, et ce qu'il faut mettre à la place.

Mais quel est l'imbélice qui a réinventé la syntaxe entre CIFS et NFS ????

Dernière modification par jimbou (Le 31/01/2024, à 10:04)

jplemoine · Le 31/01/2024, à 10:56

Tu peux tenter :

192.168.1.24:/Domoticz /media/raspberry nfs _netdev,users,noauto,bg 0 0

perso, j'ai nfs4 et pas nfs tout court
- _netdev : permet de préciser au système que c'est un lecteur réseau : à donc monter après avoir démarrer les services réseau
- bg (background) : permet de lancer un processus "fork" qui va tenter un mount dans le cas où le serveur n'est pas joignable.

NB : c'est peut-être une "vieille syntaxe" mais elle fonctionne chez moi avec un 22.04.

Il faut que le répertoire /Domoticz existe sur la cible et que /media/raspberry existe coté client et qu'il soit vide.

Dernière modification par jplemoine (Le 31/01/2024, à 10:57)

jimbou · Le 31/01/2024, à 12:17

Merci jplemoine.

Apparemment, NFS (tout comme NFS4) n'accepte pas les options username= et/ou password=.

C'est ce que j'ai trouvé sur des forums. Et effectivement, ce sont ces options qui déclenche le message d'erreur d'option.

Donc NFS n'est pas la solution pour moi. A moins qu'il y ait une solution, un package supplémentaire, qui permette l'identification NFS par username et password.

jplemoine · Le 31/01/2024, à 12:58

Après un test rapide, ce sont les droits classiques Linux qui s'appliquent.
rep1 non monté : rwxr-xr-w
Sur la cible, le répertoire est rwxr-x---
-->
rep1 monté rwxr-x---

Tu peux donc faire ce que tu veux en terme de droit.

jimbou · Le 31/01/2024, à 14:24

Le premier problème que je dois résoudre, c'est celui de l'identification.

Je veux monter sur un PC1, à travers un réseau, un volume qui se trouve sur un PC2. Sur le PC2, le partage du volume est activé, mais je n'ai pas autorisé l'accès public, pour des problèmes de confidentialité, bien sûr. Tout ça se passe dans une asso, donc un environnement peu sécurisé. Il faut donc que l'instruction de montage sur le PC1 transmette un identifiant (username=user2 et password=pwd2) qui est connu du PC2, et qui, sur ce PC2, est autorisé à accéder au volume.

C'est possible avec CIFS, mais visiblement, en passant par NFS, ça ne marche pas. Ou alors je n'ai pas trouvé.

Le deuxième problème, c'est les permissions côté PC1. Supposons que j'ai deux utilisateurs user1.1 et user1.2 sur le PC1, et que c'est user1.1 qui a monté le volume. La manip décrite ci-dessus permet à user1.1 de se faire passer pour user2 auprès du PC2. Et c'est PC1 qui présente user1.1 au PC2 en lui disant que c'est user2. Mais je voudrais que PC1 présente aussi le user1.2 au PC2 comme étant user2, et je ne comprends pas pourquoi ce n'est pas possible. Dans un environnement professionnel, à multi-utlisateurs, ça me semble un besoin très élémentaire.

D'après ce que tu me dis, les permissions du point de montage sur le PC1 sont écrasées, lors du montage, par les permissions du volume sur le PC2. Ce n'est finalement pas différent de CIFS. De mon point de vue, ça n'a pas beaucoup de sens car les utilisateurs user1.1 et user1.2 du PC1 sont différents du user2 du PC2. Mais peu importe, ça veut dire que le PC1 ne peut pas faire ce qu'il veut, il hérite forcément des permissions du volume sur le PC2.

Pardon si je suis un peu basique dans mes explications, mais j'avais besoin de ça pour bien mettre à plat mes idées.

Dernière modification par jimbou (Le 31/01/2024, à 14:42)

iznobe · Le 31/01/2024, à 14:58

Bonjour , on ne comprend rien a votre fil de discussion , ca parle de 3 problèmes différents ...

Bref , si tu veux monter un lecteur réseau , il est evident qu ' en changeant de session utilisateur , il faut alors le remonter à nouveau dans la session du second utilisateur .
Du coup , il ne faut pas passer par le fstab .

Dans un 1er temps tu fais un montage manuel .
Quand ca fonctionne , tu fais un script que l ' utilisateur lance : démontage , remontage du dossier réseau .

tu peux aussi faire la meme chose en graphique , il faut juste pas oublier de démonter le dossier réseau avant de changer de session .

et un secondaire qui est simple utilisateur, avec un sudo limité.

ca existe ca ? soit l' utilisateur a accès au préfixe sudo , soit pas . soit il fait parti des sudoers soit pas .
faut savoir , car ca change la donne , notamment le script ne sera pas valable en version " classique " ( avec sudo ) si l' utilisateur n' a pas sudo .
il faudra alors monter le dossier en version simple utilisateur dans les deux cas . je ne sais pas si " udisksctl " permet de monter des partages réseau .

Dernière modification par iznobe (Le 31/01/2024, à 15:09)

jimbou · Le 31/01/2024, à 15:17

Bonjour iznobe,

C'est peut-être évidemment impossible avec Linux, mais ça ne me semble pas logique.

Peu importe, la solution par umount puis mount dans ~/.profile est suffisante, même si pas parfaite.

Je marque le fil comme résolu.

jplemoine · Le 31/01/2024, à 15:30

iznobe a écrit :

et un secondaire qui est simple utilisateur, avec un sudo limité.
ca existe ca ? soit l' utilisateur a accès au préfixe sudo , soit pas . soit il fait parti des sudoers soit pas .

Ben non... Tu peux donner les droits sudo que pour une liste de commande limitée.
De plus, tu peux supprimer la demande de mot de passe pour toutes les commandes ou pour une série de commande.
Par exemple: sur mes PC perso, l'utilisateur principal peut lancer le script de mise à jour du système sans mot de passe mais devra le fournir pour toutes les autres commandes.

ça se passe dans le fichier /etc/sudoers que tu ne modifies plus mais tu déportes tes modifications dans des fichiers dans /etc/sudoers.d.

Dernière modification par jplemoine (Le 31/01/2024, à 15:32)

iznobe · Le 31/01/2024, à 15:36

Merci @jplemoine pour l' info , à l' occasion je chercherais à connaître ce qu ' on peut paramétrer avec sudoers . Comme je n' ai encore jamais eu la nécessité de modifier ca , je n ' avais jamais regardé de prés .

jplemoine · Le 31/01/2024, à 16:05

En perso, pas trop non plus. Mais en pro, c'est un classique...
Le cas que j'ai en tête :
Tu en as besoin, par exemple, dans certains cas, pour que des utilisateurs privilégiés (genre contact informatique) puisse gérer les imprimantes.
Ils ont droit au lpadmin (qui nécessite des droits sudo) mais pas au reste (périmètre des administrateurs systèmes)

krodelabestiole · Le 31/01/2024, à 17:17

jplemoine a écrit :

ajouter le paramètre noauto.
Cela va permettre un "prémontage" mais c'est l'utilisateur qui fera la commande et qui aura les droits rw.
En graphique, il suffit de double-cliquer sur le répertoire dans l'explorateur de fichier (la ligne dans le fstab permet qu'il appraraisse en "grisé").

woua merci, je n'avais jamais fait attention à cette fonctionnalité !
il faut que le stockage distant soit monté dans un répertoire sous /media/$USER je suppose ?

jplemoine · Le 31/01/2024, à 17:58

Perso, je les monte dans le home de l'utilisateur "normal" : /home/xxxx/rep_distant (en dur dans le fstab car il n'y a qu'un utilisateur "humain").
Mais on doit pouvoir le monter n'importe où.

Coeur Noir · Le 31/01/2024, à 18:47

il faut que le stockage distant soit monté dans un répertoire sous /media/$USER je suppose ?

Pas touche à /media/$USER
À la base /media est vide.
C'est udisks / udisksctl qui y créera un dossier $USER en cas de connexion d'un support de stockage « hotpluggable ».
Pour ne pas gêner cet automatisme - qui emploie des ACL pour gérer qui a accès à $USER dans /media - il est prudent de ne pas créer « manuellement » là un dossier $USER.

Contente toi d'un dossier /media/la_ressource_reseau portant les droits rwxrwx--- et appartenant à root:root ou root:users ou root:$USER selon à qui tu souhaites accorder des droits ( utilisateur à rendre membre de tel ou tel groupe ) dans /media/la_ressource_réseau sachant qu'une fois des données montées là-dedans, ce sont les données qui portent les droits, pas forcément les mêmes que ceux du point de montage. Donc s'assurer dans les options dudit montage qu'il accorde les droits nécessaires ( et ça, ça dépendra du système de fichiers de la ressource à monter. )

jimbou · Le 01/02/2024, à 13:46

J'ai trouvé la réponse à mon problème.

Avec CIFS, on peut utiliser les options dir_mode et file_mode qui permettent d'imposer les permissions sur les répertoires et les fichiers que l'on monte.
Avec dir_mode=0777, j'ai les permissions que je veux au point de montage et sur les répertoire de l'arborescence montée.

S'il y a dans l'arborescence montée des répertoires avec des restrictions d'accès, la commande ls -al les fait apparaitre en drwxrwxrwx, mais quand on essaye de faire quelque chose qui n'est pas autorisé par leurs permissions réelles, on se fait jeter.

Dernière modification par jimbou (Le 01/02/2024, à 14:12)

Coeur Noir · Le 01/02/2024, à 21:51

Du 777 ça signifie quand même que n'importe qui ayant accès ( physique ou distant ) à cette machine pourra faire n'importe quoi dans ce dossier~point~de~montage.

Vois si un dir_mode=0775 est suffisant, et un file_mode=0664 ( pas besoin d'exécution sur tous les fichiers. )

Les options de montage pour CiFS → https://manpages.ubuntu.com/manpages/ja … ml#options

À propos des droits et permissions → https://doc.ubuntu-fr.org/droits ⋅ https://doc.ubuntu-fr.org/permissions

Ne pas confondre les utilisateurs Linux ( uid, gid ) existant localement dans le système de la machine dans laquelle est montée le répertoire distant
avec
les utilisateurs existant sur la ou les machines distantes où se trouvent les données, potentiellement sous un autre OS et système de fichiers ( username, utilisateur propriétaire et autorisé du partage initial dans la machine distante. )

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 30/01/2024, à 11:49

[RESOLU] Problème d'accès en RW à un lecteur réseau pour tous les uti.

#2 Le 30/01/2024, à 12:07

Re : [RESOLU] Problème d'accès en RW à un lecteur réseau pour tous les uti.

#3 Le 30/01/2024, à 14:47

Re : [RESOLU] Problème d'accès en RW à un lecteur réseau pour tous les uti.

#4 Le 30/01/2024, à 15:19

Re : [RESOLU] Problème d'accès en RW à un lecteur réseau pour tous les uti.

#5 Le 30/01/2024, à 20:38

Re : [RESOLU] Problème d'accès en RW à un lecteur réseau pour tous les uti.

#6 Le 30/01/2024, à 20:56

Re : [RESOLU] Problème d'accès en RW à un lecteur réseau pour tous les uti.

#7 Le 31/01/2024, à 09:07

Re : [RESOLU] Problème d'accès en RW à un lecteur réseau pour tous les uti.

#8 Le 31/01/2024, à 09:59

Re : [RESOLU] Problème d'accès en RW à un lecteur réseau pour tous les uti.

#9 Le 31/01/2024, à 10:56

Re : [RESOLU] Problème d'accès en RW à un lecteur réseau pour tous les uti.

#10 Le 31/01/2024, à 12:17

Re : [RESOLU] Problème d'accès en RW à un lecteur réseau pour tous les uti.

#11 Le 31/01/2024, à 12:58

Re : [RESOLU] Problème d'accès en RW à un lecteur réseau pour tous les uti.

#12 Le 31/01/2024, à 14:24

Re : [RESOLU] Problème d'accès en RW à un lecteur réseau pour tous les uti.

#13 Le 31/01/2024, à 14:58

Re : [RESOLU] Problème d'accès en RW à un lecteur réseau pour tous les uti.

#14 Le 31/01/2024, à 15:17

Re : [RESOLU] Problème d'accès en RW à un lecteur réseau pour tous les uti.

#15 Le 31/01/2024, à 15:30

Re : [RESOLU] Problème d'accès en RW à un lecteur réseau pour tous les uti.

#16 Le 31/01/2024, à 15:36

Re : [RESOLU] Problème d'accès en RW à un lecteur réseau pour tous les uti.

#17 Le 31/01/2024, à 16:05

Re : [RESOLU] Problème d'accès en RW à un lecteur réseau pour tous les uti.

#18 Le 31/01/2024, à 17:17

Re : [RESOLU] Problème d'accès en RW à un lecteur réseau pour tous les uti.

#19 Le 31/01/2024, à 17:58

Re : [RESOLU] Problème d'accès en RW à un lecteur réseau pour tous les uti.

#20 Le 31/01/2024, à 18:47

Re : [RESOLU] Problème d'accès en RW à un lecteur réseau pour tous les uti.

#21 Le 01/02/2024, à 13:46

Re : [RESOLU] Problème d'accès en RW à un lecteur réseau pour tous les uti.

#22 Le 01/02/2024, à 21:51

Re : [RESOLU] Problème d'accès en RW à un lecteur réseau pour tous les uti.

Pied de page des forums