Contenu | Rechercher | Menus

Annonce

Si vous avez des soucis pour rester connecté, déconnectez-vous puis reconnectez-vous depuis ce lien en cochant la case
Me connecter automatiquement lors de mes prochaines visites.

À propos de l'équipe du forum.

#1 Le 23/01/2018, à 11:57

falcou

[Résolu] probleme de permissions sur lecteur reseau (NAS)avec systemd

Bonjour,
J'ai constaté depuis quelques temps des problèmes de droits de lecture/écriture sur  mes lecteurs réseau, que j'ai initiés depuis fstab.
Cela fait des années que ça marchait parfaitement.
Mais maintenant, impossible de renommer, ou même copier un fichier sur mon NAS.
Quand je regarde les propriétés de mes lecteurs réseau, j'ai :
propriétaire: systemd time synchronization
accès:          lecture et écriture

groupe:         users
accès:           accès aux fichiers

autre:            accès aux fichiers

Impossible de modifier ces valeurs, elles reviennent toujours, impossible de comprendre qqchose dans ce systemd, trop opaque pour moi.
Est-ce que c'est déjà arrivé de votre coté ?

Dernière modification par falcou (Le 23/01/2018, à 19:31)

Hors ligne

#2 Le 23/01/2018, à 12:14

J5012

Re : [Résolu] probleme de permissions sur lecteur reseau (NAS)avec systemd

normal en fait : avant systemd et sans arguments précisés sur la ligne fstab , les droits d'acces etaient root
avec systemd les droits sont donc systemd ...

pour eviter ca on fait comme avant : on ajoute des arguments pour redefinir les droits d'acces lors du montage ... : on fait monter par fuse comme un disque amovible ... pour ensuite recuperer les droits d'acces afin de les utiliser sur la ligne d'arguments dans fstab ... mais en general on voudra un userid de 1000 avec un groupid de 1000 ... voir la doc ...

https://doc.ubuntu-fr.org/mount_fstab
et les differents man ...
https://doc.ubuntu-fr.org/tutoriel/mont … e_commande
https://doc.ubuntu-fr.org/tutoriel/acce … hier_fstab

Hors ligne

#3 Le 23/01/2018, à 19:28

falcou

Re : [Résolu] probleme de permissions sur lecteur reseau (NAS)avec systemd

Salut J5012,
et merci! J'ai effectivement rajouté sur mes lignes de fstab, un dir_mode et un file_mod, et effectivement,
au redémarrage, je peux de nouveau écrire et renommer...
big_smile:D

Hors ligne

#4 Le 24/01/2018, à 09:47

grandtoubab

Re : [Résolu] probleme de permissions sur lecteur reseau (NAS)avec systemd

salut
Amusant ça.

Etant donné qu'il existe un groupe systemd-timesync

cat /etc/group | grep system
systemd-journal:x:102:
systemd-timesync:x:103:
systemd-network:x:104:
systemd-resolve:x:105:

Est-ce qu'on aurait pas le même résultat en ajoutant l'utilisateur ordinaire dans le groupe systemd-timesync ?


Linux tout seul sur HP Pavilion DV7 et Acer Aspire T650, Canon MG3650 en wifi
Debian 11 Bullseye Gnome/Xorg, Gnome/Wayland avec SDDM
https://bidouilledebian.wordpress.com/
ON M'A VU DANS LE VERCORS, SAUTER A L'ELASTIQUE..... J'AI DANS LES BOTTES DES MONTAGNES DE QUESTIONS....

Hors ligne

#5 Le 24/01/2018, à 19:59

J5012

Re : [Résolu] probleme de permissions sur lecteur reseau (NAS)avec systemd

@grandtoubab : oui ... mais c'est le meme probleme d'avec root et fstab avant gvfs/fuse ... si tu mettais l'utilisateur dans root alors qu'il est deja admin via sudoers sans etre root , tous les fichiers crees et à creer seraient avec des permissions root : les utilisateurs avaient tous leurs fichiers en root ... et travailaient alors en root !

le principe fuse a heureusement separé les droits et acces au montage du volume qui doivent rester root, d'avec les droits et acces au contenu qui doivent prendre ceux de l'utilisateur qui cree les fichiers ...

Hors ligne

#6 Le 25/01/2018, à 08:44

grandtoubab

Re : [Résolu] probleme de permissions sur lecteur reseau (NAS)avec systemd

J5012 a écrit :

@grandtoubab : oui ... mais c'est le meme probleme d'avec root et fstab avant gvfs/fuse ... si tu mettais l'utilisateur dans root alors qu'il est deja admin via sudoers sans etre root , tous les fichiers crees et à creer seraient avec des permissions root : les utilisateurs avaient tous leurs fichiers en root ... et travailaient alors en root !

le principe fuse a heureusement separé les droits et acces au montage du volume qui doivent rester root, d'avec les droits et acces au contenu qui doivent prendre ceux de l'utilisateur qui cree les fichiers ...

j'ai pas évoqué de modifier des droits root..
j'ai suggéré d'ajouter l'utilisateur dans le group
exemple si toto est l'utilisateur

sudo usermod -a -G systemd-timesync toto

Linux tout seul sur HP Pavilion DV7 et Acer Aspire T650, Canon MG3650 en wifi
Debian 11 Bullseye Gnome/Xorg, Gnome/Wayland avec SDDM
https://bidouilledebian.wordpress.com/
ON M'A VU DANS LE VERCORS, SAUTER A L'ELASTIQUE..... J'AI DANS LES BOTTES DES MONTAGNES DE QUESTIONS....

Hors ligne

#7 Le 25/01/2018, à 13:06

J5012

Re : [Résolu] probleme de permissions sur lecteur reseau (NAS)avec systemd

oui oui j'avais compris que tu voulais mettre l'utilisateur dans le groupe systemd-etc

mais mon exemple avec root te decrit ce qui se passait avant l'invention de gvfs/fuse, se passera aussi avec systemd-etc : l'utilisateur ne sera pas proprietaire de ses fichiers ... alors qu'il les cree ...

de plus l'utilisateur ne pourra y ecrire que si le groupe systemd-etc a aussi les droits d'ecriture ... ce qui par defaut ne l'est pas !

Dernière modification par J5012 (Le 25/01/2018, à 13:07)

Hors ligne

#8 Le 25/01/2018, à 14:47

grandtoubab

Re : [Résolu] probleme de permissions sur lecteur reseau (NAS)avec systemd

J5012 a écrit :

oui oui j'avais compris que tu voulais mettre l'utilisateur dans le groupe systemd-etc

mais mon exemple avec root te decrit ce qui se passait avant l'invention de gvfs/fuse, se passera aussi avec systemd-etc : l'utilisateur ne sera pas proprietaire de ses fichiers ... alors qu'il les cree ...

de plus l'utilisateur ne pourra y ecrire que si le groupe systemd-etc a aussi les droits d'ecriture ... ce qui par defaut ne l'est pas !

tu as un vrai problème de lecture....il s'agit du groupe
systemd-timesync
comme l' a indiqué falcou Le 23/01/2018, à 12:57
Quand je regarde les propriétés de mes lecteurs réseau, j'ai :
propriétaire: systemd time synchronization
accès:          lecture et écriture

Dernière modification par grandtoubab (Le 25/01/2018, à 14:48)


Linux tout seul sur HP Pavilion DV7 et Acer Aspire T650, Canon MG3650 en wifi
Debian 11 Bullseye Gnome/Xorg, Gnome/Wayland avec SDDM
https://bidouilledebian.wordpress.com/
ON M'A VU DANS LE VERCORS, SAUTER A L'ELASTIQUE..... J'AI DANS LES BOTTES DES MONTAGNES DE QUESTIONS....

Hors ligne

#9 Le 26/01/2018, à 12:37

J5012

Re : [Résolu] probleme de permissions sur lecteur reseau (NAS)avec systemd

oui c'est bien le cas : le proprietaire systemd-etc comme dans etc au lieu d'ecrire timesync en toutes lettres ... a acces en lecture et ecriture ! mais seulement le proprietaire du volume pas le simple utilisateur appartenant aux groupes users ou au groupe systemd-etc ... et si l'utilisateur qui a besoin de creer les fichiers dans le volume n'a acces qu'en lecture au volume il ne peut pas y ecrire par defaut , parce que par defaut il n'a pas acces en ecriture ...

post #1

Quand je regarde les propriétés de mes lecteurs réseau, j'ai :
propriétaire: systemd time synchronization
accès:          lecture et écriture

groupe:         users
accès:           accès aux fichiers

autre:            accès aux fichiers

Hors ligne

#10 Le 26/01/2018, à 12:51

Kutnjem kagho

Re : [Résolu] probleme de permissions sur lecteur reseau (NAS)avec systemd

Merci

Hors ligne

#11 Le 26/01/2018, à 15:00

maxire

Re : [Résolu] probleme de permissions sur lecteur reseau (NAS)avec systemd

Salut;

J5012 a écrit :

normal en fait : avant systemd et sans arguments précisés sur la ligne fstab , les droits d'acces etaient root
avec systemd les droits sont donc systemd

Euh, non pas vraiment, qu'est-ce qui te fait penser cela?
En réalité, l'arrivée de SystemD n'a rien changé sur le fond quant au montage des systèmes de fichiers.

Dans le cas du montage de systèmes de fichiers Unix/Linux le répertoire de montage prend pour uid/gid ceux du système de fichiers généralement root dans le cas d'un montage local.
Dans le cas des systèmes de fichiers ext tu peux jouer avec les "Reserved blocks uid et Reserved blocks gid" qui sont égaux à 0 par défaut.
SI tu les modifies via tune2fs, le répertoire de montage prendra pour propriétaire et groupe ces nouvelles valeurs.
Dans le cas de BTRFS c'est un peu différent, tout se passe au niveau des sous-volumes.
Dans le cas du montage classique (hors fuse) des systèmes de fichiers WIndows le répertoire de montage si il ne l'est pas déjà prend pour propriétaire root et groupe root par défaut.

C'est le même principe avec les montages réseaux, nfs par défaut (enfin cela dépend tout de même des options d'exportation) le répertoire de montage prend pour uid/gid les valeurs exportées par le serveur nfs, samba uid/gid par défaut 0/0 et sshfs c'est un peu plus tordu.

Un exemple de montage nfs utilisant les options de montage par défaut (ou presque je force juste la version de nfs ainsi que les protocoles de transport et de montage), vous remarquerez que le répertoire de montage passe de propriétaire/groupe root/root à musique/musique.
musique/musique  ont des valeurs exportées du serveur nfs, il se trouve juste que j'harmonise les valeurs de uid/gid entre les serveurs et les clients.

[aspire7730z@asus-arch ~]$ ls -ld /home.nfs
drwxr-xr-x 1 root root 0 14 janv.  2016 /home.nfs
[aspire7730z@asus-arch ~]$ sudo mount -t nfs -o nfsvers=3,proto=tcp,mountproto=tcp  frankenstein.home:/srv/nfsroot/Musique /home.nfs 
[aspire7730z@asus-arch ~]$ ls -ld /home.nfs
drwxrwsr-t 1 musique musique 6018 24 nov.  20:01 /home.nfs
[aspire7730z@asus-arch ~]$

Dans le cas de ce fil de discussion et n'ayant pas d'information sur le type de montage réseau utilisé réellement, je pense que cet état provient d'une migration qui par hasard a affecté à l'utilisateur systemd-timesync une valeur de uid précédemment affectée à un autre utilisateur ou même non affectée.
J'ajoute que donner pour propriétaire du montage réseau un utilisateur système spécialisé dans la synchronisation de l'horloge système me paraît sans aucun sens.

Ceci dit, le problème a été réglé en forçant uid/gid via les options de montage, c'est parfait, le problème est résolu.


Maxire
Archlinux/Mate + Ubuntu 22.04 + Archlinux/Gnome sur poste de travail

Hors ligne

#12 Le 26/01/2018, à 15:33

J5012

Re : [Résolu] probleme de permissions sur lecteur reseau (NAS)avec systemd

oui maxire j'ai trop simplifié ... merci pour l'explication extensive wink

Hors ligne

#13 Le 29/01/2018, à 18:51

falcou

Re : [Résolu] probleme de permissions sur lecteur reseau (NAS)avec systemd

C'est tres technique, tout ca,
cependant, avant j'avais cette ligne dans fstab:

//192.168.1xx /music    /multimedia/Musique    cifs    guest, iocharset=utf8, gid=100, uid=100, _netdev    0    0

et là, j'ai du la remplacer par:
//192.168.1.xx/music    /multimedia/Musique    cifs    guest, iocharset=utf8, gid=100, uid=100, _netdev, file_mode=0777, dir_mode=077    0    0

et je ne vois pas pourquoi, ça fonctionnait avant et plus avec systemd... mauvaise façon de procéder dès le début ?

Hors ligne

#14 Le 30/01/2018, à 11:47

maxire

Re : [Résolu] probleme de permissions sur lecteur reseau (NAS)avec systemd

OK, c'est donc un partage Samba (utilisation de cifs), si le propriétaire du système de fichiers a toujours eu pour id=100 il existe des chances pour que cela soit l'id de systemd-timesync  depuis un bout de temps.
gid=100, c'est généralement le  groupe users ce qui est le cas ici (lire premier message),
id=100, je ne sais pas. à vérifier en faisant:

$ getent passwd |grep -E "systemd|:100:"

Pourquoi avoir choisi id=100 dans les options de montage du partage?
Si je lis la page man de mount.cifs:

man mount.cifs a écrit :

file_mode=arg
           If the server does not support the CIFS Unix extensions this overrides the default file mode.

       dir_mode=arg
           If the server does not support the CIFS Unix extensions this overrides the default mode for directories.

Ce problème pourrait être la conséquence d'une mise à jour côté NAS aussi bien qu'une évolution des autorisations d'accès par défaut du client.
Ne connaissant pas bien CIFS, faute de l'utiliser, je me garde de donner un diagnostic ferme.
SystemD n'a rien à voir directement avec ce problème.

En tout cas il existe plein de raisons pour expliquer des problèmes d'accès avec CIFS, comme indiqué dans ce paragraphe de man mount.cifs:

man mount.cifs a écrit :

CIFS/NTFS ACL, SID/UID/GID MAPPING, SECURITY DESCRIPTORS
       This option is used to work with file objects which posses Security Descriptors and CIFS/NTFS ACL instead of UID, GID, file permission bits, and
       POSIX ACL as user authentication model. This is the most common authentication model for CIFS servers and is the one used by Windows.

       Support for this requires both CIFS_XATTR and CIFS_ACL support in the CIFS configuration options when building the cifs module.

       A CIFS/NTFS ACL is mapped to file permission bits using an algorithm specified in the following Microsoft TechNet document:

       ·   http://technet.microsoft.com/en-us/libr … 63216.aspx

       In order to map SIDs to/from UIDs and GIDs, the following is required:

       ·   a kernel upcall to the cifs.idmap utility set up via request-key.conf(5)

       ·   winbind support configured via nsswitch.conf(5) and smb.conf(5)

       Please refer to the respective manpages of cifs.idmap(8) and winbindd(8) for more information.

       Security descriptors for a file object can be retrieved and set directly using extended attribute named system.cifs_acl. The security descriptors
       presented via this interface are "raw" blobs of data and need a userspace utility to either parse and format or to assemble it such as
       getcifsacl(1) and setcifsacl(1) respectively.

       Some of the things to consider while using this mount option:

       ·   There may be an increased latency when handling metadata due to additional requests to get and set security descriptors.

       ·   The mapping between a CIFS/NTFS ACL and POSIX file permission bits is imperfect and some ACL information may be lost in the translation.

       ·   If either upcall to cifs.idmap is not setup correctly or winbind is not configured and running, ID mapping will fail. In that case uid and gid
           will default to either to those values of the share or to the values of uid and/or gid mount options if specified.


Maxire
Archlinux/Mate + Ubuntu 22.04 + Archlinux/Gnome sur poste de travail

Hors ligne

#15 Le 30/01/2018, à 18:03

falcou

Re : [Résolu] probleme de permissions sur lecteur reseau (NAS)avec systemd

allelouya !!!
Tu as mis le doigt sur le problème, Maxire.
J'ai réinstallé UBUNTU il y a quelques mois, et ré écrivant le fstab (car pas pensé à le mettre dans un coin),
et que j'ai écrit mes lignes concernant le NAS, mon clavier a fourché, et j'ai écrit uid=100, au lieu de uid=1000...
d’où la présence de systemd-timesync dans les permissions !!!

je viens de corriger, j'ai retiré mes fie_mode et dir_mode, et ça roule comme au premier jour,
je suis enfin propriétaire de mes fichiers !!

Merci bien et tous cas, j'avais vraiment un problème de compréhension de la survenue de ce problème.
Merci bien à tous et a la communauté

Hors ligne