Mount utilisateur

Bonjour,

Pour un script bash, je veux pouvoir créer des répertoires sur un disque externe de sauvegardes des données personnelles de l’utilisateur (unique) eric.

sudo mount /dev/sdb1 /media/eric/disqueUSB

permet à l’utilisateur eric de monter le volume /dev/sdb1, mais sous l’identité et le groupe root.

J’ai essayé mount -o remount,user mais il ne permet pas de créer un répertoire avec mkdir.

pmount permet de monter le volume sur un point de montage appartenant à eric, mais il ne permet pas de choisir le point de montage (monté sur /mnt/<nom> )

Par défaut j’utiliserai pmount, mais est-il possible d’utiliser mount en donnant les droits du point de montage à owner et group à eric ?

Je trouve la solution suivante:
sudo chown eric:eric /media/eric/disqueUSB
mais cette commande dans un script n’est-elle pas particulièrement imprudente?

si c’est un disque externe quand tu le branches il devrait se monter automatiquement et tu devrais y avoir accès si tu es en session eric.
Sinon il faut que tu mettes le montage dans /etc/fstab, avec l’option user et il te faut les droits rwx sur le point de montage correspondant aux propriétaires ( si dans meme groupe c’est g+rwx sinon c’est o+rwx).

Après quand tu branche le disque avec une session eric ouverte, le disque sera accessible.

Les permissions du point de montage n’ont aucun effet une fois le système de fichiers monté car elles sont masquées par les permissions de la racine du système de fichiers monté.
Quel est le type de système de fichiers ? Les permissions de FAT ou NTFS sont définies au montage. Les permissions d’ext4 peuvent être définies de façon classique avec chown et chmod une fois pour toutes.

Je me suis mal exprime, quand je parlais des droits sur le point de montage, c’est sur le repertoire qui servira au montage si le user qui monte le disque n’a pas accès à ce répertoire le point de montage échouera.

Merci pour vos réponses,

ma première question était basée sur l’absence (aléatoire) de montage automatique. Son inscription dans /etc/fstab y répond.

ma deuxième question était, dans un script la ligne: «sudo chown ...» est-elle imprudente?
Bien entendu, si j’inclus la liste de mes disques externes dans /etc/fstab, cette question devient sans objet.

je sais plus si c’est reconnu pour les disques internes mais il me semble que les DE utilisent udisksctl
sinon, dans /etc/fstab faut mettre les options qui vont bien si le disque n’est pas brancher.

merci yatta

que sont ces options ?

https://manpages.debian.org/stretch/udisks2/udisksctl.1.en.html

Merci Yatta, j’ai lu (trop superficiellement, sans doute) mais sans bien comprendre en quoi il devrait remplacer «mount».

Je vais approfondir cette lecture (avec l’aide indispensable de DeepL )

Bonjour @josephtux

Si l’on ne partage pas son ordinateur, on aurait tendance à configurer sudo de la manière la plus simple mais il est tout à fait possible de limiter l’usage de sudo à la commande mount. En créant un utilisateur « guest » et en associant sudo à la commande mount pour cet utilisateur, la présence de sudo dans un script trouve pleinement sa place sans grand risque (La meilleure façon de ne pas enfreindre la sécurité est de ne jamais utiliser un ordinateur). J’associerai aussi à sudo pour ce même utilisateur la commande umount.

Une recherche de la chaine « To run specific commands » sur cette page en anglais vous fournira un exemple d’affectation de sudo à une commande spécifique.

Le sujet ayant du mal à converger vers une solution semble-t-il, je donne mon point de vue à toutes fins utiles.
1 - udiskctl n’a pas pour fonction de gérer des droits d’écriture;
2 - je ne vois pas d’intérêt pour l’usager unique qu’est l’administrateur de configurer sudo pour s’en limiter les droits. Le seul intérêt de configuration de sudo est de ne pas demander de mot de passe à l’administrateur, quelque-soit la commande.

Je propose de rebalayer point par point le sujet.

Ok.

sudo mount /dev/sdb1 /media/eric/disqueUSB permet à l’utilisateur eric de monter le volume /dev/sdb1, mais sous l’identité et le groupe root.

Le « sudo mount » n’est pas rédibitoire relativement à l’environnement décrit d’usager unique, mais la confusion commence ici. Le montage est une opération sans rapport direct/évident avec des permissions user/group d’écriture (voir configuration partition plus bas).
A ce niveau, sudo mount permettra de monter la partition sur un point de montage imposé, et rien de plus.

J’ai essayé mount -o remount,user mais il ne permet pas de créer un répertoire avec mkdir.

Normal, ce n’est pas du tout le rôle de l’option ‹ user › de mount.

pmount permet de monter le volume
Par défaut j’utiliserai pmount, mais est-il possible d’utiliser mount en donnant les droits du point de montage à owner et group à eric ?

pmount n’est pas installé par défaut et non nécessaire pour l’usager/administrateur eric, et n’apporte rien d’interessant dans ce cas. mount ne permet pas de gérer directement par options des droits de propriété du point de montage pour de l’ext4, pas plus que pmount. mount et pmount montent, et c’est tout.

sudo chown eric:eric /media/eric/disqueUSB
cette commande dans un script n’est-elle pas particulièrement imprudente ?

La commande n’a pas d’intérêt dans le script. Une fois l’opération faite une fois sur la partition montée, le file-system retiendra les permissions définies.
――――
Donc finalement, comment faire sans trop se prendre la tête ?
Si le media disqueUSB est autorisé en usage à l’utilisateur, il est possible de passer les options de permission pour le user principal comme ceci à la partition /dev/sdb1 :
En supposant que /dev/sdb1 soit bien le périphérique (toujours vérifier):
# tune2fs -u 1000 -g 1000 /dev/sdb1
→ [ nécessite e2fsprogs installé ]

Vérification:
# tune2fs -l /dev/sdb1 |grep '[ug]id'

Passons à la pratique avec un script de vérification:

#!/bin/bash
D=/dev/sdb1
P=/media/eric/disqueUSB

if ((UID>999)) ; then echo "usager $USER autorisé: ok"
    else echo "usage interdit à $USER; bye" ; exit
fi

[ -d $P ] || mkdir $P
printf "Permissions $P : "; stat --printf="%a | %A\n" $P

echo "Montage $D sur $P :"
if sudo mount $D $P && findmnt -M $P ; then echo
   mkdir $P/_ && rm -rf $P/_ && echo "Test de création répertoire dans $P OK"
 else echo "problème de montage/écriture $D; please check" ; exit
fi

Normalement, « ça devrait bien se passer ».

Merci Verner pour cette clarification et votre modèle de script.

Reste la question de la commande tune2fs qui n’est pas applicable au système xfs: quelle commande peut la remplacer?

Pour le cas où /media/eric n’existe pas:
mkdir -p $P

Dans le montage, il n’est pas nécessaire de précise le type de filesystem ?
J’ai parfois eu des surprises si je ne précisais pas.

Etonnant que le paramètre xfs (non standard pour Debian) arrive si tardivement dans le sujet.
N’utilisant pas xfs, je ne serais pas intervenu.
A moins de chercher les complications, j’aurais été bien curieux de savoir ce qui justifie réellement un partitonnement en xfs pour du stockage de données, alors que ext4 est non seulement standard, mais dispose de ses outils:
tune2fs - adjust tunable file system parameters on ext2/ext3/ext4 file systems

xfs = complication supplémentaire, si on ne maîtrise déjà pas des opérations de base, standards.

Si xfs est si important, il faudra se contenter du « chown » récursif comme indiqué pour changer une fois les droits de la racine de montage.

C’est un choix trés ancien de --encore plus-- débutant, j’ai oublié pour quelle raison; probablement une question de gestion de l’espace disque avec beaucoup de petits fichiers en côtoyant de très gros.
Et aussi la gestion des attributs étendus qu’ext2 ne gérait pas aussi facilement à l’époque, si je me souviens bien et si j’avais bien compris…

Désolé d’avoir mésestimé l’importance de cette information.

Mais votre intervention m’a été instructive et très utile (y compris cette dernière remarque).

Effectivement, historiquement compréhensible. Un peu moins maintenant.
Mais ext4 peut être optionné avec une taille de secteur plus petit par défaut.
Ce ne sont pas ses options qui manquent.

Usage: mkfs.ext4 [-c|-l filename] [-b block-size] [-C cluster-size]
[-i bytes-per-inode] [-I inode-size] [-J journal-options]
[-G flex-group-size] [-N number-of-inodes] [-d root-directory|tarball]
[-m reserved-blocks-percentage] [-o creator-os]
[-g blocks-per-group] [-L volume-label] [-M last-mounted-directory]
[-O feature[,...]] [-r fs-revision] [-E extended-option[,...]]
[-t fs-type] [-T usage-type ] [-U UUID] [-e errors_behavior][-z undo_file]
[-jnqvDFSV] device [blocks-count]

Sinon, ce sujet complémentaire [info+script] :round_pushpin: Montage partition, apporte des informations plus générales, dont certaines pourraient paraître contradictoires avec ce cas précis, et qui démontre que le sujet partitionnement/montage est bien vaste et complexe (sauf si on ne se pose aucune question).

Tu as la commande xfs_info pour ça, xfs_repair pour la réparation et xfs_admin pour certaines opération comme modifier l’UUID, le label …

Pour chacunes des commandes explorer le man fournira le complément d’information nécessaire à leurs bon emploi.

La fiabilité, même si ext4 n’a pas à rougir, ses excellents performance à l’époque pour les très grosses volumétrie.
la dé duplication et le reflink ont été ajouté depuis quelques années, mais à vrai dire à moins d’être sur de la Redhat ou un serveur je ne vois pas non plus l’utilité d’utilisé du xfs (surtout sachant qu’il est impossible de réduire une partition xfs, seulement l’agrandir :confused: )

Merci à tous les deux, mais maintenant que c’est installé, je pense que ce serait une nouvelle complication de remplacer ce système.

Je m’en souviendrai pour un avenir potentiel.

Mais s’il fallait faire un nouveau choix, pourquoi pas btrfs qui intègre les fonction LVM, si j’ai bien compris.
btrfs présente-t-il aussi des complications pour un éternel béotien récalcitrant comme moi?

Je ne souhaite pas rentrer dans un débat sur quel est le meilleur ‹ file-system › dans ce sujet (HS).
Il y a plein de sujets de comparaisons (que je ne mets pas en lien car en anglais).
L’herbe est toujours plus verte ailleurs si on se concentre sur un seul paramètre, dont a peut-être aucun besoin, et qu’on oublie par exemple de préciser les inconvénients, qu’on découvrira ultérieurement.
Questions annexes:

  • quelle sera la durée de vie du file-system X,Y,Z ? Maintenu par qui ?
  • existe-t-il des outils de récupération de données pour le file-system moins standard ?
    Ce n’est pas le jour où on perd par erreur de manip 500Go de data qu’il faut se poser la question.

Bonne réflexion, pour le prochain formatage.
Ext4 vs XFS – Lequel choisir ?
Introduction au système de fichiers Btrfs
Comprendre et utiliser le système de fichiers BtrFS sous Linux

1 J'aime