# Mount utilisateur **URL:** \ **Category:** Support Debian\ **Created:** [Août 17, 2024, 3:14 UTC](https://www.debian-fr.org/t/mount-utilisateur/90280 "2024-08-17T15:14:08Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![josephtux](https://www.debian-fr.org/user_avatar/www.debian-fr.org/josephtux/32/3985_2.png) [@josephtux](https://www.debian-fr.org/u/josephtux)\ **Post date:** [Août 17, 2024, 3:14 UTC](https://www.debian-fr.org/t/mount-utilisateur/90280/1 "2024-08-17T15:14:08Z")
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/\ ) 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 ? ---
**Author:** ![josephtux](https://www.debian-fr.org/user_avatar/www.debian-fr.org/josephtux/32/3985_2.png) [@josephtux](https://www.debian-fr.org/u/josephtux)\ **Post date:** [Août 17, 2024, 3:28 UTC](https://www.debian-fr.org/t/mount-utilisateur/90280/2 "2024-08-17T15:28:32Z")
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? ---
**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\ **Post date:** [Septembre 5, 2024, 8:50 UTC](https://www.debian-fr.org/t/mount-utilisateur/90280/3 "2024-09-05T20:50:03Z")
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. ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Septembre 5, 2024, 8:55 UTC](https://www.debian-fr.org/t/mount-utilisateur/90280/4 "2024-09-05T20:55:50Z")
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. ---
**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\ **Post date:** [Septembre 5, 2024, 9:05 UTC](https://www.debian-fr.org/t/mount-utilisateur/90280/5 "2024-09-05T21:05:23Z")
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. ---
**Author:** ![josephtux](https://www.debian-fr.org/user_avatar/www.debian-fr.org/josephtux/32/3985_2.png) [@josephtux](https://www.debian-fr.org/u/josephtux)\ **Post date:** [Septembre 6, 2024, 1:13 UTC](https://www.debian-fr.org/t/mount-utilisateur/90280/6 "2024-09-06T13:13:52Z")
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. ---
**Author:** ![yatta](https://www.debian-fr.org/user_avatar/www.debian-fr.org/yatta/32/12132_2.png) [@yatta](https://www.debian-fr.org/u/yatta)\ **Post date:** [Septembre 7, 2024, 8:14 UTC](https://www.debian-fr.org/t/mount-utilisateur/90280/7 "2024-09-07T08:14:39Z")
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. ---
**Author:** ![josephtux](https://www.debian-fr.org/user_avatar/www.debian-fr.org/josephtux/32/3985_2.png) [@josephtux](https://www.debian-fr.org/u/josephtux)\ **Post date:** [Septembre 7, 2024, 1:42 UTC](https://www.debian-fr.org/t/mount-utilisateur/90280/8 "2024-09-07T13:42:32Z")
> [@yatta](#): > > les options qui vont bien _si le disque n’est pas branche_ merci yatta que sont ces options ? ---
**Author:** ![yatta](https://www.debian-fr.org/user_avatar/www.debian-fr.org/yatta/32/12132_2.png) [@yatta](https://www.debian-fr.org/u/yatta)\ **Post date:** [Septembre 8, 2024, 12:01 UTC](https://www.debian-fr.org/t/mount-utilisateur/90280/9 "2024-09-08T00:01:48Z")
> [@yatta](#): > > udisksctl > **[udisksctl(1) — udisks2 — Debian stretch — Debian Manpages](https://manpages.debian.org/stretch/udisks2/udisksctl.1.en.html)** ---
**Author:** ![josephtux](https://www.debian-fr.org/user_avatar/www.debian-fr.org/josephtux/32/3985_2.png) [@josephtux](https://www.debian-fr.org/u/josephtux)\ **Post date:** [Septembre 8, 2024, 9:00 UTC](https://www.debian-fr.org/t/mount-utilisateur/90280/10 "2024-09-08T09:00:09Z")
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 ) ---
**Author:** ![vbreton](https://www.debian-fr.org/user_avatar/www.debian-fr.org/vbreton/32/11400_2.png) [@vbreton](https://www.debian-fr.org/u/vbreton)\ **Post date:** [Septembre 9, 2024, 7:30 UTC](https://www.debian-fr.org/t/mount-utilisateur/90280/11 "2024-09-09T07:30:07Z")
Bonjour @josephtux > [@josephtux](#): > > ma deuxième question était, dans un script la ligne: « `sudo chown ...` » est-elle imprudente? 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](https://kifarunix.com/run-only-specific-commands-with-sudo-in-linux/) en anglais vous fournira un exemple d’affectation de sudo à une commande spécifique. ---
**Author:** ![Verner](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/v/34f0e0/32.png) [@Verner](https://www.debian-fr.org/u/Verner)\ **Post date:** [Septembre 10, 2024, 8:32 UTC](https://www.debian-fr.org/t/mount-utilisateur/90280/12 "2024-09-10T20:32:37Z")
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. > [@josephtux](#): > > 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. 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: ```auto #!/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_ ». ---
**Author:** ![josephtux](https://www.debian-fr.org/user_avatar/www.debian-fr.org/josephtux/32/3985_2.png) [@josephtux](https://www.debian-fr.org/u/josephtux)\ **Post date:** [Septembre 11, 2024, 11:11 UTC](https://www.debian-fr.org/t/mount-utilisateur/90280/13 "2024-09-11T11:11:49Z")
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? ---
**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\ **Post date:** [Septembre 11, 2024, 11:39 UTC](https://www.debian-fr.org/t/mount-utilisateur/90280/14 "2024-09-11T11:39:42Z")
> [@Verner](#): > > `[-d $P] || mkdir $P` 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. ---
**Author:** ![Verner](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/v/34f0e0/32.png) [@Verner](https://www.debian-fr.org/u/Verner)\ **Post date:** [Septembre 11, 2024, 11:44 UTC](https://www.debian-fr.org/t/mount-utilisateur/90280/15 "2024-09-11T11:44:33Z")
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. ---
**Author:** ![josephtux](https://www.debian-fr.org/user_avatar/www.debian-fr.org/josephtux/32/3985_2.png) [@josephtux](https://www.debian-fr.org/u/josephtux)\ **Post date:** [Septembre 11, 2024, 11:50 UTC](https://www.debian-fr.org/t/mount-utilisateur/90280/16 "2024-09-11T11:50:48Z")
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). ---
**Author:** ![Verner](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/v/34f0e0/32.png) [@Verner](https://www.debian-fr.org/u/Verner)\ **Post date:** [Septembre 11, 2024, 12:07 UTC](https://www.debian-fr.org/t/mount-utilisateur/90280/17 "2024-09-11T12:07:23Z")
> [@josephtux](#): > > probablement une question de gestion de l’espace disque avec beaucoup de petits fichiers en côtoyant de très gros. 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. ```plaintext 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] 📍 Montage partition](https://www.debian-fr.org/t/info-script-montage-partition-image-iso-disque-squashfs-pour-lusager-lambda/90310), 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). ---
**Author:** ![Clochette](https://www.debian-fr.org/user_avatar/www.debian-fr.org/clochette/32/8757_2.png) [@Clochette](https://www.debian-fr.org/u/Clochette)\ **Post date:** [Septembre 11, 2024, 12:40 UTC](https://www.debian-fr.org/t/mount-utilisateur/90280/18 "2024-09-11T12:40:27Z")
> [@josephtux](#): > > Reste la question de la commande `tune2fs` qui n’est pas applicable au système `xfs` : quelle commande peut la remplacer? 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. > [@Verner](#): > > 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 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 😕 ) ---
**Author:** ![josephtux](https://www.debian-fr.org/user_avatar/www.debian-fr.org/josephtux/32/3985_2.png) [@josephtux](https://www.debian-fr.org/u/josephtux)\ **Post date:** [Septembre 11, 2024, 12:48 UTC](https://www.debian-fr.org/t/mount-utilisateur/90280/19 "2024-09-11T12:48:13Z")
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? ---
**Author:** ![Verner](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/v/34f0e0/32.png) [@Verner](https://www.debian-fr.org/u/Verner)\ **Post date:** [Septembre 11, 2024, 1:06 UTC](https://www.debian-fr.org/t/mount-utilisateur/90280/20 "2024-09-11T13:06:05Z")
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 ?](https://fr.linux-console.net/?p=21530) → [Introduction au système de fichiers **Btrfs**](https://fr.linux-console.net/?p=16500) → [Comprendre et utiliser le système de fichiers **BtrFS** sous Linux](https://fr.linux-console.net/?p=22226)