Linux Mint 19.2 64 bits Enregistrement refusé sur clé USB
25 réponses
Blobb
Bonjour,
je débute dans Linux, j'ai exploré nombre de tutos, et je ne parviens pas à "e;e;démarrer"e;e; son utilisation.
Mon Linux Mint 19.2 64 bits est installé sur mon SSD interne du portable.
Je souhaite enregistrer un PDF sur ma clé USB et le message suivant apparaît :
Le fichier ne peut pas être enregistré car vous n’avez pas les permissions nécessaires. Choisissez un autre répertoire d’enregistrement.
Voici les infos de ma clé USB :
Système de fichiers : ext4
UUID 43a715c9-65e4-4c28-b6e0-e3b959d750c0
Etat : Montée sur /media/bpp/43a715c9-65e4-4c28-b6e0-e3b959d750c0
Chemin : /dev/sdb1
jp willm , dans le message <qq769u$2lic$, a écrit :
Sauf à avoir un droit d'écriture par exemple.
Et que fais-tu avec ce droit d'écriture sur le périphérique, exactement ?
Personnellement, quand je fais un sudo chown -R user:user /dev/machin/chouette je n'ai plus à le refaire par la suite pour le même périphérique.
En effet : comme ça n'a rien changé, tu n'as pas besoin de le refaire, tu n'avais même pas besoin de le faire la première fois.
Pascal Hambourg
Le 09/11/2019 à 16:37, jp willm a écrit :
Le 09/11/2019 à 11:09, Pascal Hambourg a écrit :
Non. Il ne sert à rien de modifier les droits sur le périphérique,
J'ai pris l'habitude de modifier les droits sur le périphérique, mais cela ne m'a jamais posé de problème...
Les permissions en lecture et en écriture sur une partition permettent l'accès direct à celle-ci sans passer par le système de fichiers, donc de la formater, l'effacer, la cloner ou en faire une image. Et bien sûr toutes les erreurs et bêtises imaginables. Cela n'a aucun effet sur l'accès normal aux fichiers lorsque le système de fichiers est monté. Cela ne permet que l'accès direct aux fichiers dans un volume non monté via des programmes spécifiques comme mtools pour FAT ou ntfsprogs (maintenant inclus dans ntfs-3g) pour NTFS.
il faut le faire sur la racine du système de fichiers en question, donc le point de montage /media/bpp/43a715c9-65e4-4c28-b6e0-e3b959d750c0.
J'avoue que cela me semble plus logique, mais aussi sélectif, car seul ce système de fichier sera concerné et il faudra refaire la manipulation pour tout autre média amovible au format ext4 (disque dur, SDcard etc.).
Mais au moins les permissions sur ce système fichiers sont persistantes, contrairement à ta manipulation sur le fichier spécial de périphérique. A moins d'avoir un système qui utilise encore un /dev statique, /dev est maintenant une instance de tmpfs ou devtmpfs (système de fichiers temporaire en mémoire volatile) dont le contenu est géré dynamiquement par udev au gré de l'apparition et de la disparition des périphériques. Donc si tu redémarres le système ou débranches et rebranches la clé, les permissions sont réinitialisées. Sans parler du fait qu'elle peut changer de nom de périphérique.
Accessoirement, plutôt que changer le propriétaire (ce qui n'a pas de sens si cette clé est amenée à être partagée entre plusieurs ordinateurs), changer les permissions pour donner le droit en écriture à tout le monde avec chmod 777.
D'accord, mais faut-il le faire avec l'option -R ?
Non. Si l'utilisateur n'avait pas la permission d'écrire, le volume devrait être vide à l'exception du répertoire spécial lost+found dont je ne suis pas sûr que ce soit une bonne idée de modifier les permissions.
Le 09/11/2019 à 16:37, jp willm a écrit :
Le 09/11/2019 à 11:09, Pascal Hambourg a écrit :
Non. Il ne sert à rien de modifier les droits sur le périphérique,
J'ai pris l'habitude de modifier les droits sur le périphérique, mais
cela ne m'a jamais posé de problème...
Les permissions en lecture et en écriture sur une partition permettent
l'accès direct à celle-ci sans passer par le système de fichiers, donc
de la formater, l'effacer, la cloner ou en faire une image. Et bien sûr
toutes les erreurs et bêtises imaginables.
Cela n'a aucun effet sur l'accès normal aux fichiers lorsque le système
de fichiers est monté. Cela ne permet que l'accès direct aux fichiers
dans un volume non monté via des programmes spécifiques comme mtools
pour FAT ou ntfsprogs (maintenant inclus dans ntfs-3g) pour NTFS.
il faut le faire sur la racine du système de fichiers en question,
donc le point de montage /media/bpp/43a715c9-65e4-4c28-b6e0-e3b959d750c0.
J'avoue que cela me semble plus logique, mais aussi sélectif, car seul
ce système de fichier sera concerné et il faudra refaire la manipulation
pour tout autre média amovible au format ext4 (disque dur, SDcard etc.).
Mais au moins les permissions sur ce système fichiers sont persistantes,
contrairement à ta manipulation sur le fichier spécial de périphérique.
A moins d'avoir un système qui utilise encore un /dev statique, /dev est
maintenant une instance de tmpfs ou devtmpfs (système de fichiers
temporaire en mémoire volatile) dont le contenu est géré dynamiquement
par udev au gré de l'apparition et de la disparition des périphériques.
Donc si tu redémarres le système ou débranches et rebranches la clé, les
permissions sont réinitialisées. Sans parler du fait qu'elle peut
changer de nom de périphérique.
Accessoirement, plutôt que changer le propriétaire (ce qui n'a pas de
sens si cette clé est amenée à être partagée entre plusieurs
ordinateurs), changer les permissions pour donner le droit en écriture
à tout le monde avec chmod 777.
D'accord, mais faut-il le faire avec l'option -R ?
Non. Si l'utilisateur n'avait pas la permission d'écrire, le volume
devrait être vide à l'exception du répertoire spécial lost+found dont je
ne suis pas sûr que ce soit une bonne idée de modifier les permissions.
Non. Il ne sert à rien de modifier les droits sur le périphérique,
J'ai pris l'habitude de modifier les droits sur le périphérique, mais cela ne m'a jamais posé de problème...
Les permissions en lecture et en écriture sur une partition permettent l'accès direct à celle-ci sans passer par le système de fichiers, donc de la formater, l'effacer, la cloner ou en faire une image. Et bien sûr toutes les erreurs et bêtises imaginables. Cela n'a aucun effet sur l'accès normal aux fichiers lorsque le système de fichiers est monté. Cela ne permet que l'accès direct aux fichiers dans un volume non monté via des programmes spécifiques comme mtools pour FAT ou ntfsprogs (maintenant inclus dans ntfs-3g) pour NTFS.
il faut le faire sur la racine du système de fichiers en question, donc le point de montage /media/bpp/43a715c9-65e4-4c28-b6e0-e3b959d750c0.
J'avoue que cela me semble plus logique, mais aussi sélectif, car seul ce système de fichier sera concerné et il faudra refaire la manipulation pour tout autre média amovible au format ext4 (disque dur, SDcard etc.).
Mais au moins les permissions sur ce système fichiers sont persistantes, contrairement à ta manipulation sur le fichier spécial de périphérique. A moins d'avoir un système qui utilise encore un /dev statique, /dev est maintenant une instance de tmpfs ou devtmpfs (système de fichiers temporaire en mémoire volatile) dont le contenu est géré dynamiquement par udev au gré de l'apparition et de la disparition des périphériques. Donc si tu redémarres le système ou débranches et rebranches la clé, les permissions sont réinitialisées. Sans parler du fait qu'elle peut changer de nom de périphérique.
Accessoirement, plutôt que changer le propriétaire (ce qui n'a pas de sens si cette clé est amenée à être partagée entre plusieurs ordinateurs), changer les permissions pour donner le droit en écriture à tout le monde avec chmod 777.
D'accord, mais faut-il le faire avec l'option -R ?
Non. Si l'utilisateur n'avait pas la permission d'écrire, le volume devrait être vide à l'exception du répertoire spécial lost+found dont je ne suis pas sûr que ce soit une bonne idée de modifier les permissions.
jp willm
Le 10/11/2019 à 08:48, Pascal Hambourg a écrit :
Les permissions en lecture et en écriture sur une partition permettent l'accès direct à celle-ci sans passer par le système de fichiers, donc de la formater, l'effacer, la cloner ou en faire une image. Et bien sûr toutes les erreurs et bêtises imaginables.
Bon j'ai pas l'air fier là, d'autant plus que Nicolas George me chambre depuis un moment sans que je comprenne pourquoi :-/ J'avais oublié que je lançais un sudo chown contenant le UUID du périphérique (exemple: sudo chown -R user:user/run/media/jp/0d2f0d9a-b7ce-4e3c-9a3d-7e3d838bc9a4).
Cela n'a aucun effet sur l'accès normal aux fichiers lorsque le système de fichiers est monté.
Je comprends. Cela ne permet que l'accès direct aux fichiers
dans un volume non monté via des programmes spécifiques comme mtools pour FAT ou ntfsprogs (maintenant inclus dans ntfs-3g) pour NTFS.
Ce n'est pas ce que l'on cherche présentement. Désolé pour le trouble que j'ai occasionné en ne vérifiant pas mes dires. Merci pour tes explications utiles et ta patience ! -- jp willm http://willms.yj.fr/willms/index.html
Le 10/11/2019 à 08:48, Pascal Hambourg a écrit :
Les permissions en lecture et en écriture sur une partition permettent
l'accès direct à celle-ci sans passer par le système de fichiers, donc
de la formater, l'effacer, la cloner ou en faire une image. Et bien sûr
toutes les erreurs et bêtises imaginables.
Bon j'ai pas l'air fier là, d'autant plus que Nicolas George me chambre
depuis un moment sans que je comprenne pourquoi :-/
J'avais oublié que je lançais un sudo chown contenant le UUID du
périphérique (exemple: sudo chown -R
user:user/run/media/jp/0d2f0d9a-b7ce-4e3c-9a3d-7e3d838bc9a4).
Cela n'a aucun effet sur l'accès normal aux fichiers lorsque le système
de fichiers est monté.
Je comprends.
Cela ne permet que l'accès direct aux fichiers
dans un volume non monté via des programmes spécifiques comme mtools
pour FAT ou ntfsprogs (maintenant inclus dans ntfs-3g) pour NTFS.
Ce n'est pas ce que l'on cherche présentement.
Désolé pour le trouble que j'ai occasionné en ne vérifiant pas mes dires.
Merci pour tes explications utiles et ta patience !
Les permissions en lecture et en écriture sur une partition permettent l'accès direct à celle-ci sans passer par le système de fichiers, donc de la formater, l'effacer, la cloner ou en faire une image. Et bien sûr toutes les erreurs et bêtises imaginables.
Bon j'ai pas l'air fier là, d'autant plus que Nicolas George me chambre depuis un moment sans que je comprenne pourquoi :-/ J'avais oublié que je lançais un sudo chown contenant le UUID du périphérique (exemple: sudo chown -R user:user/run/media/jp/0d2f0d9a-b7ce-4e3c-9a3d-7e3d838bc9a4).
Cela n'a aucun effet sur l'accès normal aux fichiers lorsque le système de fichiers est monté.
Je comprends. Cela ne permet que l'accès direct aux fichiers
dans un volume non monté via des programmes spécifiques comme mtools pour FAT ou ntfsprogs (maintenant inclus dans ntfs-3g) pour NTFS.
Ce n'est pas ce que l'on cherche présentement. Désolé pour le trouble que j'ai occasionné en ne vérifiant pas mes dires. Merci pour tes explications utiles et ta patience ! -- jp willm http://willms.yj.fr/willms/index.html
jp willm
Le 09/11/2019 à 21:53, Nicolas George a écrit :
En effet : comme ça n'a rien changé, tu n'as pas besoin de le refaire, tu n'avais même pas besoin de le faire la première fois.
Bon, ben ça va, j'ai compris... enfin. J'aurais mieux fait de vérifier avant de claironner n'importe quoi :-/ Heureusement qu'il reste des piliers sur ce forum pour corriger les amateurs distraits comme moi :) -- jp willm http://willms.yj.fr/willms/index.html
Le 09/11/2019 à 21:53, Nicolas George a écrit :
En effet : comme ça n'a rien changé, tu n'as pas besoin de le refaire,
tu n'avais même pas besoin de le faire la première fois.
Bon, ben ça va, j'ai compris... enfin.
J'aurais mieux fait de vérifier avant de claironner n'importe quoi :-/
Heureusement qu'il reste des piliers sur ce forum pour corriger les
amateurs distraits comme moi :)
En effet : comme ça n'a rien changé, tu n'as pas besoin de le refaire, tu n'avais même pas besoin de le faire la première fois.
Bon, ben ça va, j'ai compris... enfin. J'aurais mieux fait de vérifier avant de claironner n'importe quoi :-/ Heureusement qu'il reste des piliers sur ce forum pour corriger les amateurs distraits comme moi :) -- jp willm http://willms.yj.fr/willms/index.html
jp willm
Le 09/11/2019 à 07:41, jp willm a écrit :
sudo chown -R Blobb:Blobb /dev/sdb1
J'ai dit n'importe quoi ! Comme l'explique Pascal Hambourg : "Il ne sert à rien de modifier les droits sur le périphérique, il faut le faire sur la racine du système de fichiers en question, donc le point de montage /media/bpp/43a715c9-65e4-4c28-b6e0-e3b959d750c0" Donc, c'est plutôt : sudo chown -R bpp:bpp /media/bpp/43a715c9-65e4-4c28-b6e0-e3b959d750c0 -- jp willm http://willms.yj.fr/willms/index.html
Le 09/11/2019 à 07:41, jp willm a écrit :
sudo chown -R Blobb:Blobb /dev/sdb1
J'ai dit n'importe quoi !
Comme l'explique Pascal Hambourg :
"Il ne sert à rien de modifier les droits sur le périphérique, il faut
le faire sur la racine du système de fichiers en question, donc le point
de montage /media/bpp/43a715c9-65e4-4c28-b6e0-e3b959d750c0"
Donc, c'est plutôt :
sudo chown -R bpp:bpp /media/bpp/43a715c9-65e4-4c28-b6e0-e3b959d750c0
J'ai dit n'importe quoi ! Comme l'explique Pascal Hambourg : "Il ne sert à rien de modifier les droits sur le périphérique, il faut le faire sur la racine du système de fichiers en question, donc le point de montage /media/bpp/43a715c9-65e4-4c28-b6e0-e3b959d750c0" Donc, c'est plutôt : sudo chown -R bpp:bpp /media/bpp/43a715c9-65e4-4c28-b6e0-e3b959d750c0 -- jp willm http://willms.yj.fr/willms/index.html
Pascal Hambourg
Le 10/11/2019 à 16:08, jp willm a écrit :
J'avais oublié que je lançais un sudo chown contenant le UUID du périphérique (exemple: sudo chown -R user:user/run/media/jp/0d2f0d9a-b7ce-4e3c-9a3d-7e3d838bc9a4).
Je vais pinailler encore un peu. Il ne s'agit pas à proprement parler de l'UUID du périphérique mais de l'UUID du système de fichiers qu'il contient. La distinction est importante car cet UUID identifie le contenu et non le contenant, donc change en cas de reformatage. Il existe un autre type d'UUID de partition (PARTUUID) qui identifie une partition indépendammment de son contenu et ne change pas en cas de reformatage. D'autre part, /run/media/<user>/<uuid> (ou /media/<user>/<uuid> selon la distribution) est un point de montage créé dynamiquement pour monter le système de fichiers et nommé à partir de son UUID, mais c'est arbitraire (et pas très joli ni explicite). Si une étiquette (LABEL) est définie, c'est plutôt elle qui est utilisée pour nommer le point de montage. Dans les deux cas, ne pas confondre ce point de montage avec les liens symboliques dans /dev/disk/by-uuid/<uuid> et /dev/disk/by-label/<label> qui pointent vers le périphérique dont le contenu a cet UUID ou ce LABEL.
Le 10/11/2019 à 16:08, jp willm a écrit :
J'avais oublié que je lançais un sudo chown contenant le UUID du
périphérique (exemple: sudo chown -R
user:user/run/media/jp/0d2f0d9a-b7ce-4e3c-9a3d-7e3d838bc9a4).
Je vais pinailler encore un peu.
Il ne s'agit pas à proprement parler de l'UUID du périphérique mais de
l'UUID du système de fichiers qu'il contient. La distinction est
importante car cet UUID identifie le contenu et non le contenant, donc
change en cas de reformatage. Il existe un autre type d'UUID de
partition (PARTUUID) qui identifie une partition indépendammment de son
contenu et ne change pas en cas de reformatage.
D'autre part, /run/media/<user>/<uuid> (ou /media/<user>/<uuid> selon la
distribution) est un point de montage créé dynamiquement pour monter le
système de fichiers et nommé à partir de son UUID, mais c'est arbitraire
(et pas très joli ni explicite). Si une étiquette (LABEL) est définie,
c'est plutôt elle qui est utilisée pour nommer le point de montage. Dans
les deux cas, ne pas confondre ce point de montage avec les liens
symboliques dans /dev/disk/by-uuid/<uuid> et /dev/disk/by-label/<label>
qui pointent vers le périphérique dont le contenu a cet UUID ou ce LABEL.
J'avais oublié que je lançais un sudo chown contenant le UUID du périphérique (exemple: sudo chown -R user:user/run/media/jp/0d2f0d9a-b7ce-4e3c-9a3d-7e3d838bc9a4).
Je vais pinailler encore un peu. Il ne s'agit pas à proprement parler de l'UUID du périphérique mais de l'UUID du système de fichiers qu'il contient. La distinction est importante car cet UUID identifie le contenu et non le contenant, donc change en cas de reformatage. Il existe un autre type d'UUID de partition (PARTUUID) qui identifie une partition indépendammment de son contenu et ne change pas en cas de reformatage. D'autre part, /run/media/<user>/<uuid> (ou /media/<user>/<uuid> selon la distribution) est un point de montage créé dynamiquement pour monter le système de fichiers et nommé à partir de son UUID, mais c'est arbitraire (et pas très joli ni explicite). Si une étiquette (LABEL) est définie, c'est plutôt elle qui est utilisée pour nommer le point de montage. Dans les deux cas, ne pas confondre ce point de montage avec les liens symboliques dans /dev/disk/by-uuid/<uuid> et /dev/disk/by-label/<label> qui pointent vers le périphérique dont le contenu a cet UUID ou ce LABEL.
jp willm
Le 10/11/2019 à 17:57, Pascal Hambourg a écrit :
Je vais pinailler encore un peu.
Pinaillage accepté avec plaisir :)
Il ne s'agit pas à proprement parler de l'UUID du périphérique mais de l'UUID du système de fichiers qu'il contient. La distinction est importante car cet UUID identifie le contenu et non le contenant, donc change en cas de reformatage.
En effet, l'UUID d'une partition change après reformatage et il faut parfois même modifier /etc/fstab pour que grub ne se vautre pas. Il existe un autre type d'UUID de
partition (PARTUUID) qui identifie une partition indépendammment de son contenu et ne change pas en cas de reformatage.
sudo blkid nous indique les deux, je viens de vérifier.
D'autre part, /run/media/<user>/<uuid> (ou /media/<user>/<uuid> selon la distribution) est un point de montage créé dynamiquement pour monter le système de fichiers et nommé à partir de son UUID, mais c'est arbitraire (et pas très joli ni explicite). Si une étiquette (LABEL) est définie, c'est plutôt elle qui est utilisée pour nommer le point de montage.
C'est ce qui m'a induit en erreur quand j'ai faussement affirmé que je commettais un sudo chown -R user:user /dev/<sdxy>. J'avais en fait affaire à des systèmes de fichiers possédant déjà une étiquette et dans ce cas c'était du genre : sudo chown -R user:user /run/media/<user>/<LABEL> Dans
les deux cas, ne pas confondre ce point de montage avec les liens symboliques dans /dev/disk/by-uuid/<uuid> et /dev/disk/by-label/<label> qui pointent vers le périphérique dont le contenu a cet UUID ou ce LABEL.
Je ne connaissais pas et ne vois pas qui/quoi utilise ces liens. Merci ! -- jp willm http://willms.yj.fr/willms/index.html
Le 10/11/2019 à 17:57, Pascal Hambourg a écrit :
Je vais pinailler encore un peu.
Pinaillage accepté avec plaisir :)
Il ne s'agit pas à proprement parler de l'UUID du périphérique mais de
l'UUID du système de fichiers qu'il contient. La distinction est
importante car cet UUID identifie le contenu et non le contenant, donc
change en cas de reformatage.
En effet, l'UUID d'une partition change après reformatage et il faut
parfois même modifier /etc/fstab pour que grub ne se vautre pas.
Il existe un autre type d'UUID de
partition (PARTUUID) qui identifie une partition indépendammment de son
contenu et ne change pas en cas de reformatage.
sudo blkid nous indique les deux, je viens de vérifier.
D'autre part, /run/media/<user>/<uuid> (ou /media/<user>/<uuid> selon la
distribution) est un point de montage créé dynamiquement pour monter le
système de fichiers et nommé à partir de son UUID, mais c'est arbitraire
(et pas très joli ni explicite). Si une étiquette (LABEL) est définie,
c'est plutôt elle qui est utilisée pour nommer le point de montage.
C'est ce qui m'a induit en erreur quand j'ai faussement affirmé que je
commettais un sudo chown -R user:user /dev/<sdxy>.
J'avais en fait affaire à des systèmes de fichiers possédant déjà une
étiquette et dans ce cas c'était du genre :
sudo chown -R user:user /run/media/<user>/<LABEL>
Dans
les deux cas, ne pas confondre ce point de montage avec les liens
symboliques dans /dev/disk/by-uuid/<uuid> et /dev/disk/by-label/<label>
qui pointent vers le périphérique dont le contenu a cet UUID ou ce LABEL.
Je ne connaissais pas et ne vois pas qui/quoi utilise ces liens.
Il ne s'agit pas à proprement parler de l'UUID du périphérique mais de l'UUID du système de fichiers qu'il contient. La distinction est importante car cet UUID identifie le contenu et non le contenant, donc change en cas de reformatage.
En effet, l'UUID d'une partition change après reformatage et il faut parfois même modifier /etc/fstab pour que grub ne se vautre pas. Il existe un autre type d'UUID de
partition (PARTUUID) qui identifie une partition indépendammment de son contenu et ne change pas en cas de reformatage.
sudo blkid nous indique les deux, je viens de vérifier.
D'autre part, /run/media/<user>/<uuid> (ou /media/<user>/<uuid> selon la distribution) est un point de montage créé dynamiquement pour monter le système de fichiers et nommé à partir de son UUID, mais c'est arbitraire (et pas très joli ni explicite). Si une étiquette (LABEL) est définie, c'est plutôt elle qui est utilisée pour nommer le point de montage.
C'est ce qui m'a induit en erreur quand j'ai faussement affirmé que je commettais un sudo chown -R user:user /dev/<sdxy>. J'avais en fait affaire à des systèmes de fichiers possédant déjà une étiquette et dans ce cas c'était du genre : sudo chown -R user:user /run/media/<user>/<LABEL> Dans
les deux cas, ne pas confondre ce point de montage avec les liens symboliques dans /dev/disk/by-uuid/<uuid> et /dev/disk/by-label/<label> qui pointent vers le périphérique dont le contenu a cet UUID ou ce LABEL.
Je ne connaissais pas et ne vois pas qui/quoi utilise ces liens. Merci ! -- jp willm http://willms.yj.fr/willms/index.html
Pascal Hambourg
Le 12/11/2019 à 10:45, jp willm a écrit :
Le 10/11/2019 à 17:57, Pascal Hambourg a écrit :
Dans les deux cas, ne pas confondre ce point de montage avec les liens symboliques dans /dev/disk/by-uuid/<uuid> et /dev/disk/by-label/<label> qui pointent vers le périphérique dont le contenu a cet UUID ou ce LABEL.
Je ne connaissais pas et ne vois pas qui/quoi utilise ces liens.
On peut les utiliser dans tous les cas où il faut spécifier un périphérique de façon persistante mais où on ne peut pas utiliser la syntaxe de type UUID=<uuid> ou LABEL=<label>. Il me semble que certaines versions de mount minimalistes comme celle de klibc ou busybox sont ou ont été dans ce cas.
Le 12/11/2019 à 10:45, jp willm a écrit :
Le 10/11/2019 à 17:57, Pascal Hambourg a écrit :
Dans
les deux cas, ne pas confondre ce point de montage avec les liens
symboliques dans /dev/disk/by-uuid/<uuid> et
/dev/disk/by-label/<label> qui pointent vers le périphérique dont le
contenu a cet UUID ou ce LABEL.
Je ne connaissais pas et ne vois pas qui/quoi utilise ces liens.
On peut les utiliser dans tous les cas où il faut spécifier un
périphérique de façon persistante mais où on ne peut pas utiliser la
syntaxe de type UUID=<uuid> ou LABEL=<label>. Il me semble que certaines
versions de mount minimalistes comme celle de klibc ou busybox sont ou
ont été dans ce cas.
Dans les deux cas, ne pas confondre ce point de montage avec les liens symboliques dans /dev/disk/by-uuid/<uuid> et /dev/disk/by-label/<label> qui pointent vers le périphérique dont le contenu a cet UUID ou ce LABEL.
Je ne connaissais pas et ne vois pas qui/quoi utilise ces liens.
On peut les utiliser dans tous les cas où il faut spécifier un périphérique de façon persistante mais où on ne peut pas utiliser la syntaxe de type UUID=<uuid> ou LABEL=<label>. Il me semble que certaines versions de mount minimalistes comme celle de klibc ou busybox sont ou ont été dans ce cas.
jp willm
Le 12/11/2019 à 22:32, Pascal Hambourg a écrit :
On peut les utiliser dans tous les cas où il faut spécifier un périphérique de façon persistante mais où on ne peut pas utiliser la syntaxe de type UUID=<uuid> ou LABEL=<label>. Il me semble que certaines versions de mount minimalistes comme celle de klibc ou busybox sont ou ont été dans ce cas.
Il y a quelques années je ne voyais pas de UUID ni de PARTUUID dans /etc/fstab. On a peut-être conservé ces liens symboliques pour les processus de montage restés à l'ancienne, comme ceux que tu cites ? -- jp willm http://willms.yj.fr/willms/index.html
Le 12/11/2019 à 22:32, Pascal Hambourg a écrit :
On peut les utiliser dans tous les cas où il faut spécifier un
périphérique de façon persistante mais où on ne peut pas utiliser la
syntaxe de type UUID=<uuid> ou LABEL=<label>. Il me semble que certaines
versions de mount minimalistes comme celle de klibc ou busybox sont ou
ont été dans ce cas.
Il y a quelques années je ne voyais pas de UUID ni de PARTUUID dans
/etc/fstab.
On a peut-être conservé ces liens symboliques pour les processus de
montage restés à l'ancienne, comme ceux que tu cites ?
On peut les utiliser dans tous les cas où il faut spécifier un périphérique de façon persistante mais où on ne peut pas utiliser la syntaxe de type UUID=<uuid> ou LABEL=<label>. Il me semble que certaines versions de mount minimalistes comme celle de klibc ou busybox sont ou ont été dans ce cas.
Il y a quelques années je ne voyais pas de UUID ni de PARTUUID dans /etc/fstab. On a peut-être conservé ces liens symboliques pour les processus de montage restés à l'ancienne, comme ceux que tu cites ? -- jp willm http://willms.yj.fr/willms/index.html
blobb
Le vendredi 08 Novembre 2019 à 19:27 par Blobb :
Bonjour, je débute dans Linux, j'ai exploré nombre de tutos, et je ne parviens pas à "e;e;démarrer"e;e; son utilisation. Mon Linux Mint 19.2 64 bits est installé sur mon SSD interne du portable. Je souhaite enregistrer un PDF sur ma clé USB et le message suivant apparaît : Le fichier ne peut pas être enregistré car vous n’avez pas les permissions nécessaires. Choisissez un autre répertoire d’enregistrement. Voici les infos de ma clé USB : Système de fichiers : ext4 UUID 43a715c9-65e4-4c28-b6e0-e3b959d750c0 Etat : Montée sur /media/bpp/43a715c9-65e4-4c28-b6e0-e3b959d750c0 Chemin : /dev/sdb1 et mes permissions sur le Terminal : drwxrwxr-x 2 bpp bpp 4096 nov. 4 17:14 Bureau drwxrwxr-x 2 bpp bpp 4096 nov. 4 17:14 Documents drwxrwxr-x 2 bpp bpp 4096 nov. 4 17:14 Images drwxrwxr-x 2 bpp bpp 4096 nov. 4 17:14 Modèles drwxrwxr-x 2 bpp bpp 4096 nov. 4 17:14 Musique drwxrwxr-x 2 bpp bpp 4096 nov. 4 17:14 Public drwxrwxr-x 2 bpp bpp 4096 nov. 8 18:11 Téléchargements drwxrwxr-x 2 bpp bpp 4096 nov. 4 17:14 Vidéos Quelqu'un saurait il m'expliquer comment procéder : - pour que je puisse enregistrer sur ma clé USB ? - afin que je dispose DEFINITIVEMENT de Toutes les permissions ? Avec mes plus vifs remerciements ! Blobb
Bonjour et un grand merci à vous tous pour vos réponses nombreuses. Pardon pour mon retard, j'étais absent quelques jours. Je vais bien éplucher tout ce que vous m'avez écrit pour en tirer le meilleur afin de me dépatouiller au mieux dans ma maîtrise novice de Linux Mint. Et je reviendrai pour donner la suite des résultats de mes manipulations. Avec toute ma reconnaissance. Bien cordialement Blobb
Le vendredi 08 Novembre 2019 à 19:27 par Blobb :
> Bonjour,
> je débute dans Linux, j'ai exploré nombre de tutos, et je ne
> parviens pas à "e;e;démarrer"e;e; son utilisation.
>
> Mon Linux Mint 19.2 64 bits est installé sur mon SSD interne du
> portable.
>
> Je souhaite enregistrer un PDF sur ma clé USB et le message suivant
> apparaît :
>
> Le fichier ne peut pas être enregistré car vous n’avez
> pas les permissions nécessaires. Choisissez un autre répertoire
> d’enregistrement.
>
> Voici les infos de ma clé USB :
> Système de fichiers : ext4
> UUID 43a715c9-65e4-4c28-b6e0-e3b959d750c0
> Etat : Montée sur /media/bpp/43a715c9-65e4-4c28-b6e0-e3b959d750c0
> Chemin : /dev/sdb1
>
> et mes permissions sur le Terminal :
> drwxrwxr-x 2 bpp bpp 4096 nov. 4 17:14 Bureau
> drwxrwxr-x 2 bpp bpp 4096 nov. 4 17:14 Documents
> drwxrwxr-x 2 bpp bpp 4096 nov. 4 17:14 Images
> drwxrwxr-x 2 bpp bpp 4096 nov. 4 17:14 Modèles
> drwxrwxr-x 2 bpp bpp 4096 nov. 4 17:14 Musique
> drwxrwxr-x 2 bpp bpp 4096 nov. 4 17:14 Public
> drwxrwxr-x 2 bpp bpp 4096 nov. 8 18:11 Téléchargements
> drwxrwxr-x 2 bpp bpp 4096 nov. 4 17:14 Vidéos
>
> Quelqu'un saurait il m'expliquer comment procéder :
>
> - pour que je puisse enregistrer sur ma clé USB ?
> - afin que je dispose DEFINITIVEMENT de Toutes les permissions ?
>
> Avec mes plus vifs remerciements !
> Blobb
Bonjour et un grand merci à vous tous pour vos réponses nombreuses.
Pardon pour mon retard, j'étais absent quelques jours.
Je vais bien éplucher tout ce que vous m'avez écrit pour en tirer le meilleur afin de me dépatouiller au mieux dans ma maîtrise novice de Linux Mint.
Et je reviendrai pour donner la suite des résultats de mes manipulations.
Avec toute ma reconnaissance.
Bien cordialement
Blobb
Bonjour, je débute dans Linux, j'ai exploré nombre de tutos, et je ne parviens pas à "e;e;démarrer"e;e; son utilisation. Mon Linux Mint 19.2 64 bits est installé sur mon SSD interne du portable. Je souhaite enregistrer un PDF sur ma clé USB et le message suivant apparaît : Le fichier ne peut pas être enregistré car vous n’avez pas les permissions nécessaires. Choisissez un autre répertoire d’enregistrement. Voici les infos de ma clé USB : Système de fichiers : ext4 UUID 43a715c9-65e4-4c28-b6e0-e3b959d750c0 Etat : Montée sur /media/bpp/43a715c9-65e4-4c28-b6e0-e3b959d750c0 Chemin : /dev/sdb1 et mes permissions sur le Terminal : drwxrwxr-x 2 bpp bpp 4096 nov. 4 17:14 Bureau drwxrwxr-x 2 bpp bpp 4096 nov. 4 17:14 Documents drwxrwxr-x 2 bpp bpp 4096 nov. 4 17:14 Images drwxrwxr-x 2 bpp bpp 4096 nov. 4 17:14 Modèles drwxrwxr-x 2 bpp bpp 4096 nov. 4 17:14 Musique drwxrwxr-x 2 bpp bpp 4096 nov. 4 17:14 Public drwxrwxr-x 2 bpp bpp 4096 nov. 8 18:11 Téléchargements drwxrwxr-x 2 bpp bpp 4096 nov. 4 17:14 Vidéos Quelqu'un saurait il m'expliquer comment procéder : - pour que je puisse enregistrer sur ma clé USB ? - afin que je dispose DEFINITIVEMENT de Toutes les permissions ? Avec mes plus vifs remerciements ! Blobb
Bonjour et un grand merci à vous tous pour vos réponses nombreuses. Pardon pour mon retard, j'étais absent quelques jours. Je vais bien éplucher tout ce que vous m'avez écrit pour en tirer le meilleur afin de me dépatouiller au mieux dans ma maîtrise novice de Linux Mint. Et je reviendrai pour donner la suite des résultats de mes manipulations. Avec toute ma reconnaissance. Bien cordialement Blobb
