Salut;
J5012 a écritnormal 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.
