Écriture des données sur le périphérique usb

Tanguy, .L.J. · Le 11/03/2023, à 18:49

Bonjour,

Ma situation depuis hier :
je place un fichier sur clé usb (petit pdf, rien de gros, très basique),

je démonte la clé, et là ce message m'arrive :

Écriture des données sur le périphérique
Des données doivent être écrites sur me périphérique "volume" avant sa déconnexion. Veuillez ne pas retirer le support ou déconnecter le lecteur

Je retire la clé du lecteur, je l'y remets, et mes anciens fichiers sont restés,

Problème : PAS les nouveaux ! - ils ont disparu, ou n'y ont pas été enregistrés.

j'ai regardé divers topics, mais j'ai l'impression que personne n'a trouvé de solution à ce problème lorsqu'il survient (le plus ancien que j'ai vu date de 2013 & 2016 pour le plus récent).

J'utilise Thunar, par acquis de conscience j'ai essayé pcmanfm, mais le résultat est le même.

Merci

Coeur Noir · Le 11/03/2023, à 19:05

Hello,

C'est drôle ça, tu as un message qui te dit : « Veuillez ne pas retirer le support ou déconnecter le lecteur » et toi tu fais quand même un : « Je retire la clé du lecteur »

Il suffit d'attendre, normalement quand l'écriture est finie, tu as une autre notification qui te dit en gros, vous pouvez débrancher le périphérique.

Maintenant, si cette deuxième notification n'arrive jamais, il faudrait vérifier l'état de cette clé USB, c'est pas éternel ces petites bêtes.

Tanguy, .L.J. · Le 11/03/2023, à 19:18

Merci Coeur Noir,

Ouais, c'est drôle, 5 minutes, curieusement ça devient vite lassant,
j'ai essayé avec d'autres clés, c'est pareil.

Dans l'absolu je t'aurais dit "oui", mais c'est pour ça que j'ai précisé, pour un pauvre petit pdf, ça va vite normalement ça.

j'ai pas encore essayé de mettre un nouveau fichier sur une autre partition de disque interne, faire un reboot et voir si c'est resté ou pas.

matrix-bx · Le 11/03/2023, à 20:00

Salut,
sauf erreur, la commande sync est faite pour ça (je la lance en sudo par habitude).

Tanguy, .L.J. · Le 11/03/2023, à 20:48

Merci matrix-bx,

La commande sync doit effectivement avoir un rôle à jouer,
je l'ai rentrée dans un terminal,
j'ai réussi à placer un fichier sur ma clé usb,
j'ai voulu démonter le volume, le message d'erreur est revenu,

puis j'ai reconnecté ma clé : le fichier y est toujours, ça c'est génial,
pour le supprimer, il faut être en root, et quand je déconnecte & reconnecte la clé, en fait il y est toujours.

une fois sur 2 j'ai l'impression que les options supprimer, coller, créer... sont grisées.

Et puis, ça recommence, tout pareil, il y a eu une lueur d'espoir, ça a marché pour UN fichier.

Coeur Noir · Le 11/03/2023, à 21:35

Je me doutais bien aussi que ça ne serait pas si simple ;-)

Quelque chose qui gênerait ou empêcherait le mécanisme des montages automatiques de supports amovibles ?

ls -la /media

ls -la /media/$USER

pour vérifier les droits dans les dossiers concernés par ces montages automatiques.

find ~ ! -user $USER

pour s'assurer que tout t'appartient dans ton répertoire perso' : quand tout va bien, cette commande ne répond rien.
Sinon tu montres ( si certains éléments cachés ne t'appartiennent plus, ça peut empêcher les montages auto' ).

Une des clés capricieuses branchée :

lsblk -fe7,11 -o +ro,size     # bien agrandir la fenêtre du terminal AVANT de lancer cette commande, sa réponse est un tableau assez large.

et

mount | grep ^/dev/

pour avoir une idée du contexte ( disques et partitions en présence et infos les concernant. )

Tanguy, .L.J. · Le 11/03/2023, à 23:34

Merci Coeur Noir,

voici les retours :

~$ ls -la /media
total 28
drwxr-xr-x   7 coucou vip  4096 mai   19  2017 .
drwxr-xr-x  26 root   root 4096 mars   3 12:26 ..
drwxrwxrwx+  5 coucou vip  4096 mars  11 19:57 anotherway
drwxr-x---+  2 coucou vip  4096 févr.  2  2020 coucou
drwxr-xr-x   2 root   root 4096 mai   19  2017 coucou1
drwxr-xr-x   2 root   root 4096 mars   3  2017 usbdisk
drwxr-xr-x   2 root   root 4096 avril  6  2017 youpi

~$ ls -la /media/$USER
total 40
drwxrwxrwx+ 5 coucou     vip         4096 mars  11 19:57  .
drwxr-xr-x  7 coucou     vip         4096 mai   19  2017  ..
drwxr-xr-x  2 anotherway anotherway  4096 janv.  1  1970 'ANOTHER WAY'
drwxrwxrwx  2 coucou     vip         4096 janv.  4  2015  MultiKey
drwxrwxrwx  1 anotherway anotherway 24576 mars  11 19:13  Stock_01

~$ find ~ ! -user $USER
/home/anotherway/.local/share/gvfs-metadata/home
/home/anotherway/.local/share/gvfs-metadata/home-5b64bdcc.log
/home/anotherway/.local/share/gvfs-metadata/home-a0d3be6d.log
/home/anotherway/.local/share/gvfs-metadata/home-b2020f67.log
/home/anotherway/.config/xarchiver
find: ‘/home/anotherway/.config/xarchiver’: Permission non accordée
/home/anotherway/.config/ibus/bus/2aaa10cb93485c7258433939542b768c-unix-1
/home/anotherway/.config/libreoffice/4_Ancien/user/extensions/shared/log.txt
/home/anotherway/.jpilot/jpilot.alarms
/home/anotherway/.cache/blueman-applet-0
/home/anotherway/.cache/dconf
find: ‘/home/anotherway/.cache/dconf’: Permission non accordée
/home/anotherway/.cache/doc
find: ‘/home/anotherway/.cache/doc’: Permission non accordée
/home/anotherway/.cache/gvfs-burn
find: ‘/home/anotherway/.cache/gvfs-burn’: Permission non accordée
/home/anotherway/.cache/gnome-shell
find: ‘/home/anotherway/.cache/gnome-shell’: Permission non accordée
find: ‘/home/anotherway/.gvfs’: Permission non accordée
/home/anotherway/.gvfs

~$ lsblk -fe7,11 -o +ro,size
NAME   FSTYPE LABEL            UUID                                 MOUNTPOINT                    RO   SIZE
sda
sdc                                                                                                0   981M
└─sdc1 vfat   ANOTHER WAY      5B19-7DA8                            /media/anotherway/ANOTHER WAY  0 980,9M

~$ mount | grep ^/dev/
/dev/sda9 on / type ext4 (rw,relatime,errors=remount-ro,stripe=32639,data=ordered)
/dev/sda6 on /home type ext4 (rw,relatime,data=ordered)
/dev/sda5 on /media/anotherway/Stock_01 type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096,uhelper=udisks2)
/dev/fuse on /run/user/1000/doc type fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
/dev/sdc1 on /media/anotherway/ANOTHER WAY type vfat (rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2)

Donc on est sur un utilisateur qui s'appelle anotherway, avec quelques tests,
j'ai viré une partie des retours (.cache de mozilla, libreoffice)

Comme je vois ce qui est sur la clé, je ne pense pas que ce soit un problème de montage, ni même automatique, puisqu'il m'ouvre Thunar dans le répertoire de la clé lorsque je l'insère.

Merci

Dernière modification par Tanguy, .L.J. (Le 11/03/2023, à 23:36)

Coeur Noir · Le 12/03/2023, à 01:11

Rappel, au cas où : la commande sudo

⋅ on s'en sert uniquement pour des actions qui ont lieu dans un terminal ou dans une console ;
⋅ on ne s'en sert JAMAIS pour lancer une application graphique ( qui ouvre sa propre fenêtre en dehors du terminal. )

…au risque de modifier des droits et permissions sur des éléments de ton répertoire personnel, provoquant des incohérences de fonctionnement ( par ex. ce qui t'arrive en ce moment )
voire des blocages ( par ex. connexion impossible à la session graphique. )

Dans un $HOME = le répertoire personnel d'un utilisateur = /home/$USER = ~ = /home/anotherway/
TOUT est censé appartenir au titulaire du $HOME ( au moins à travers le groupe propriétaire ).
Dans ce TOUT il y a des éléments visibles ( documents et médias ) et des éléments cachés ( paramètres, préférences, réglages, configurations… du moindre logiciel utilisé par le titulaire de ce $HOME )
Parmi ces éléments cachés, certains servent à établir une communication entre le système ( qui relève du SuperUtilisateur, root, 0 ) et un utilisateur authentifié ( anotherway, par ex. )
et ceux-là pourront nécessiter des droits plus restrictifs ( impérativement l'utilisateur comme propriétaire, aucun droit pour les autres. )

Bon, bah cette communication root↔$USER, chez toi, elle est probablement un peu pétée :

find ~ -name ".*" ! -user $USER -exec ls -l {} \;

devrait réduire la liste aux seuls éléments cachés, et montrer les attributs des éléments, qu'on sache à qui ils appartiennent.
Je subodore root par mésusage de sudo parce que c'est une erreur fréquente mais comme tu es peut-être dans un contexte multi-utilisateurs, il peut s'agir d'autre chose.

C'est réparable, mais le problème c'est qu'il y a d'autres endroits où les droits et permissions ne sont pas du tout conformes :
le dossier /media est un dossier système conventionnel, attendu, c'est normal et souhaitable qu'il appartienne à root:root avec droits rwxr-xr-x ;
les dossiers /media/$USER font l'objet d'une gestion particulière des droits via des ACL, eux aussi appartiennent à root:root avec droits rwxr-x---+ ( le + à la fin indiquant la présence d'ACL. )

~$ ls -la /media
total 28
drwxr-xr-x   7 coucou vip  4096 mai   19  2017 .		# droits ok | proprios KO
drwxr-xr-x  26 root   root 4096 mars   3 12:26 ..		# droits et proprios ok
drwxrwxrwx+  5 coucou vip  4096 mars  11 19:57 anotherway	# droits et proprios KO
drwxr-x---+  2 coucou vip  4096 févr.  2  2020 coucou		# droits ok | proprios KO
(…)

Le dossier /media à la racine du système est l'emplacement conventionnel pour recevoir les montages de données amovibles ( utiles pour les humains mais pas vitales au système. )
Le système se sert automatiquement de /media/$USER/ comme destination des points de montage pour les supports amovibles~nomades ( genre clé usb, carte mémoire, cd, DD externe… )
et ce qui est monté là-dedans par l'automatisme du système n'est accessible qu'à l'$USER concerné. C'est fait exprès - via les ACL. Ça permet à l'$USER de faire ce qu'il veut dans la clé USB qu'il vient de brancher, par ex.

On ne crée pas manuellement de points de montages sous /media/$USER : on laisse la pleine jouissance de ce dossier au système ( qui y crée et efface des points de montage, au besoin )
sinon on introduit des risques de confusion ( des dossiers créés là manuellement ne s'y effaceront pas, même lorsqu'ils ne sont plus des points de montage. )

À quoi servent les dossiers : coucou, coucou1, usbdisk et youpi dans /media ? J'ai l'impression que coucou est un utilisateur.
Les autres ? Je ne suis pas sûr car le retour de la commande lsblk est incomplet ce qui empêche de voir s'ils servent de point de montage.
Et du coup j'ai un doute sur le retour de la commande mount : est-il complet ?

Car oui, on peut tout à fait créer des points de montage « manuellement » sous /media « tout court », et sur ( ou dans ) ces dossiers créés là, gérer les droits et permissions en fonction des besoins ( qui, quel utilisateur, quel groupe peut faire quoi dans l'élément ). Mais on ne touche ni aux droits et permissions de /media ( il est par défaut accessible en lecture à tout le monde ) ni à ceux de /media/$USER ( dans lequel on ne crée rien manuellement, celui-là on le laisse au système ).

À partir du moment où ( et tant que ) des points de montages existent dans /media, ils apparaissent automatiquement dans l'interface graphique ( signets dans le volet latéral de l'explorateur de fichiers, icônes dans le dock ou sur le bureau ou ailleurs, selon paramètres de l'env. de bureau. )

Résumé : comme c'est le foutoir dans les droits et permissions de ton $HOME, de /media et /media/$USER
ça explique fort fort fort probablement les couacs avec tes montages de supports amovibles ( qui ne se font pas avec les droits utiles pour les utilisateurs espérés…)

____________________________________________

Alors que fait-on maintenant ?
On devrait pouvoir réparer les droits et permissions dans ton $HOME ( quand on aura vu le retour de la commande find plus haut ).
Ainsi que sur /media et /media/$USER mais ça ne résoudra pas le problème de fond :

Prudence avec sudo et les droits et permissions, surtout côté système ! Es-tu intervenu sur d'autres dossiers système ?
Dis-toi bien que la plupart du temps, il n'y a jamais besoin de sudo - on ne s'en sert que pour administrer le système, prendre les privilèges du chef, temporairement.
Dans les privilèges du SuperUtilisateur il y a la possibilité de tout détruire, hein.

De base, le seul endroit où anotherway peut lire-écrire-modifier-supprimer-exécuter, c'est dans /home/anotherway/ ; ailleurs, les éléments lui accordent peu ou aucun droit.
Si anotherway cherche à faire des choses dans le système il devra temporairement prendre les privilèges de root.
S'il cherche à faire des choses dans un dossier appartenant à coucou, ça se gère via les droits, permissions, groupe sur ce dossier appartenant à coucou
( par ex. anotherway est membre du groupe coucou et ce dossier appartenant à coucou accorde aussi les droits lecture+écriture au groupe coucou dont anotherway est membre. )

Et ça ce n'est valable que pour les systèmes de fichiers natifs Linux gérant ces attributs, mais on s'éloigne du sujet initial là.
Quoi que : cette discussion suggère que tu subis ce problème depuis un moment…
Rassure-moi, tes OS ne sont pas que des mises à niveau successives ? Qui traîneraient les mêmes $HOME depuis toutes ces années ?
Ça pourrait être une cause d'ennuis ( à cause des vieux éléments cachés, plus forcément adaptés aux versions plus récentes des OS et logiciels. )
Et le dossier /media n'a pas toujours fonctionné de cette façon, non plus.
Sans compter les nouveaux formats logiciels « confinés » qui seront plus exigeants sur les droits et permissions ( snap, flatpak ).

Docs : sudo ⋅ Droits ⋅ Permissions ⋅ droits spéciaux ( en Anglais ) ⋅ Système de Fichiers
Et svp lire aussi « Retour commande » ↓ en signature, ci-dessous.

Dernière modification par Coeur Noir (Le 13/03/2023, à 02:30)

Tanguy, .L.J. · Le 13/03/2023, à 16:52

Merci beaucoup pour tous ces renseignements Coeur Noir,

je vais juste recentrer un peu sur le soucis, sinon effectivement, ça part un peu dans tous les sens...

je suis bien connecté sur le compte anotherway (je tronque un peu les résultats - J'ai parfois peur que les retours soient un peu "intrusifs"),

~$ ls -la /media # J'avoue ne pas bien comprendre, ma clé, elle est dans /media/$USER

~$ ls -la /media/$USER
drwxr-xr-x  2 anotherway anotherway  4096 janv.  1  1970 'ANOTHER WAY'

pourtant, je ne lui ai pas créé de point de montage à la main en "vip" (je suppose) à cette clé, juste un label à la partition lors du formatage, j'ai laissé le système faire le reste.

~$ lsblk -fe7,11 -o +ro,size
NAME   FSTYPE LABEL            UUID                                 MOUNTPOINT                    RO   SIZE
sda
sdc                                                                                                0   981M
└─sdc1 vfat   ANOTHER WAY      5B19-7DA8                            /media/anotherway/ANOTHER WAY  0 980,9M

~$ mount | grep ^/dev/
/dev/sdc1 on /media/anotherway/ANOTHER WAY type vfat (rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2)

(je ne comprends pas pourquoi il n'était pas en sdb, mais bon...)

---

~$ find ~ -name ".*" ! -user $USER -exec ls -l {} \;
find: ‘/home/anotherway/.config/xarchiver’: Permission non accordée
find: ‘/home/anotherway/.cache/dconf’: Permission non accordée
find: ‘/home/anotherway/.cache/doc’: Permission non accordée
find: ‘/home/anotherway/.cache/gvfs-burn’: Permission non accordée
find: ‘/home/anotherway/.cache/gnome-shell’: Permission non accordée
ls: impossible d'ouvrir le répertoire '/home/anotherway/.gvfs': Permission non accordée
find: ‘/home/anotherway/.gvfs’: Permission non accordée

Si je comprends bien, il y a ici quelques dossiers auxquels je devrais avoir les permissions,
c'est mofiable à coups de chown -R anotherway monrepertoire & chmod -R drwXr-Xr-X ?
ça serait à cause de ça que je ne peux plus écrire sur ma clé...?

---

Après, la discussion à laquelle tu fais allusion porte sur des partitions disparues, la faute à NTFS, ou Toshiba...

Oui, je me suis amusé, comme ça, le dimanche, à créer des comptes fictifs, histoire de rigoler, faire un peu connaissance avec Linux, la console, etc.

Donc oui, des /home sur disques externes, ou pas, que j'utilisais avec différentes distributions, ou clés bootables,
oui, j'aurais dû utiliser gksudo, bon, le fstab, sera le seul point "système" que j'aurais osé toucher en root, et je ne l'ai pas refait depuis des années, jusqu'à ce WE, parce que, l'écriture sur la clé dysfonctionne, j'ai fait un sudo Thunar (sur ma clé, 1ou2 dossiers, rien du système)
Et donc depuis des années, donc aucun snap ou flatpack ici.

---

J'ai voulu reformater la clé, mais GParted me dit qu'on ne peut pas chevaucher 2 partitions,
une fois il a indiqué avoir réussi à supprimer la partition, mais qu'il ne pouvait pas le montrer,
je joue avec des partitions depuis longtemps maintenant, des messages d'erreurs incompréhensibles parce que trop techniques pour moi, j'en ai eu 2~3, mais des comme ça, jamais.
Je pense donc que ma clé est foutue (et une autre aussi peut-être)...

---

En essayant une clé plus récente, dès sa connexion j'ai l'impression qu'elle se met en root, je ne peux même pas coller un fichier dedans,
(mais là c'est justifié, c'est un problème de droits, la commande "coller" (supprimer, créer, ...) est grisée).

Pourtant,

~$ ls -la /media/$USER
total 28
drwxr-xr-x  4 anotherway anotherway 16384 janv.  1  1970 86E3-D486

Le propriétaire est en drwx, mais ne peut pas créer ou coller des fichiers...?
(...enfin... Cette clé-là au moins, quand je mets quelque chose dessus, ça reste.)

---

Quant au message d'erreur, que j'écrive quelque chose ou non sur la clé, à la déconnexion, il me prie toujours de bien vouloir le laisser finir... ...ce qu'il n'a pas commencé...

Merci pour les infos en tous cas, j'ai vu des choses que je ne connaissais pas, dont polkit, qui me paraît intéressant (même si l'inconvénient est de laisser tourner un démon...)

xubu1957 · Le 13/03/2023, à 17:00

Bonjour,

Merci de montrer, pour les permissions :

nany a écrit :

echo -e "\nNombre d'éléments de /home/moi ne m'appartenant pas : $(sudo find ~ \( ! -user $USER -o ! -group $USER \) | wc -l)"

Si le chiffre est différent de zéro :

Une commande corrective pour les permissions, et diverses explications.

Coeur Noir · Le 14/03/2023, à 03:38

Nope, Xubu, pas dans ce cas - on est potentiellement dans un contexte multi-utilisateurs, ça serait donc possible qu'on trouve dans les $HOME de A et B des éléments appartenant à l'un comme à l'autre mais avec un groupe propriétaire commun qui ne serait ni A ni B…

Par contre sur les éléments cachés ça ne devrait pas arriver.
Je préférerais savoir à qui appartiennent actuellement les éléments cachés avant d'en changer les propriétaires, histoire de cerner un peu la cause du changement :
⋅ si c'est root → usage inopportun de sudo
⋅ si c'est un autre utilisateur « humain » → éléments en provenance, par déplacement~couper~coller, d'un autre $HOME ; ou éléments créés par A dans le $HOME de B ( et vice-versa ).

On peut à nouveau tenter d'y voir plus clair avec

find ~ -name ".*" ! -user $USER -exec sudo ls -l {} \;

qui demandera le mot de passe admin'.

Mais dans l'absolu si on ne souhaite pas en savoir davantage, on peut déjà réattribuer ces éléments cachés à l'$USER de la session courante :

find ~ -name ".*" ! -user $USER -exec sudo chown -Rc $USER:$USER {} \;

-R comme récursif car on vise les éléments ET leur contenu.
Ça ne peut pas faire de mal de revenir à la situation par défaut.

Et surtout réparer les dossiers /media et /media/$USER : pars du principe que c'est super rarissime d'avoir à changer des droits et permissions de dossiers système.
Il est par défaut plutôt bien conçu et réglé.

______________________

Le fonctionnement du dossier /media n'a rien de mystérieux, il a une ( histoire et une ) logique :
illustration provenant d'un autre fil de discussion

pour expliquer QUAND le système se sert de /media/$USER soit
dès lors qu'il rencontre un périphérique de stockage qui n'est pas déjà consigné dans le fichier /etc/fstab

______________________

ça serait à cause de ça que je ne peux plus écrire sur ma clé...?

Entre autres : les droits ne sont pas corrects non plus sur /media et /media/$USER et ça c'est plus embêtant :
⋅ il faut savoir comment c'est arrivé ; et t'en prémunir ! Ou te l'interdire ( car je suspecte que tu as fait ça manuellement en croyant bien faire )
⋅ ce sont les dossiers qui servent de destinations aux montages automatiques de données ou de supports amovibles, leurs situations actuellement inadéquates a ( probablement | forcément ) des répercussions sur cet automatisme.
Edit : par excès de prudence, les commandes suivantes sont à passer alors qu'aucun support nomade~amovible n'est branché.

sudo chown -c root:root {/media,/media/anotherway,/media/coucou}
sudo chmod -c 755 /media
sudo chmod -c 750 /media/anotherway

Pas de récursif ici, on ne vise bien que ces dossiers, pas leur contenu.
Avoir des difficultés d'écriture sur clé usb ne doit pas être le seul problème que tu rencontres avec ce système, vu les éléments cachés auxquels ton utilisateur n'a peut-être plus du tout accès, ou partiellement.

______________________

Donc oui, des /home sur disques externes, ou pas, que j'utilisais avec différentes distributions,

Youpi. Et merci les défenseurs du fumeux concept de « partition /home séparée ».

Les éléments cachés ( préférences, paramètres, configurations ) du $HOME de l'utilisateur A dans le système B de version C sont complètement relatifs et interdépendants. Ce sont des données spécifiques à cet utilisateur dans ce système à cette version et aux versions du moindre logiciel que A y emploie.
Les éléments visibles ( documents, médias ) eux ne poseront pas problème car ils n'ont aucune incidence sur le fonctionnement de la session ou du système ( hormis la place qu'ils prennent ), contrairement aux éléments cachés dont certains « dialoguent » avec le système. Le terme « dialoguent » est techniquement impropre mais illustratif.

En prenant les éléments cachés du $HOME de A pour les mettre dans un système Y de version Z, c'est impossible de garantir le fonctionnement correct de la session de A dans ce système Y de version Z puisque ce sont à la base des configurations prévues pour le système B de version C.

Ça fonctionnera peu ou prou dans un même système qui passe gentiment à sa version suivante via une mise à niveau dans des conditions idéales ( finalement plutôt rares ). Autrement, c'est comme le cumul d'environnements de bureau, c'est risquer des imbroglios inextricables dans les paramètres et configurations de la session utilisateur. Ou à minima stocker des infos inutiles, obsolètes.

Donc une recommandation : dans ton système actuel, crée un nouvel utilisateur de type administrateur, histoire d'avoir sous le coude une session « vierge », sans passif.
Et déjà, regarde dans cette session si le comportement des clés y est « normal » ( après impérative réparation des dossiers /media et /media/$USER. )

De là, tu pourrais rapatrier toutes les données visibles des utilisateurs - et uniquement les visibles - et utiliser cette base saine comme session principale… on pourrait discuter ailleurs de ce qui resterait à faire, des stratégies envisageables.

______________________

Mmm… complètement vrai aussi : des clés usb, ça périt. Les vérifier par ailleurs.

Dernière modification par Coeur Noir (Le 16/03/2023, à 03:55)

Tanguy, .L.J. · Le 15/03/2023, à 05:37

Merci Coeur Noir & Xubu1957,

bon... oui, déjà moi je croyais que quand on voulait modifier des droits sur des répertoires, il fallait le paramètre -R à chaque fois, et donc immanquablement, leurs contenus,
et donc ça me faisait très bizarre que l'accès USB soit root:root et que tout le monde puisse y prendre & déposer ce qu'il veut,
ok, je fais confiance au système (...parce que c'est Linux )

Oui, j'ai vu qu'il y a des / qui peuvent modifier le HOME, le but, c'était d'avoir un HOME un peu nomade, pour des profiles de firefox, par exemple,
ou le partager entre un noyau classique et un realtime,
un truc amusant, quand un dossier avec du contenu est désigné comme point de montage, le temps du montage, il s'ouvre sur la partition montée, et au démontage, il ouvre à nouveau sur le contenu initial,
voilà... ...il m'en faut peu, bah, des p'tits tests quoi... (...j'ai même fait du "sudo startx" à une époque où effectivement je jouait avec des environnements différents, beaucoup (TROP) d'environnements différents, en passant des heures sur Compiz sur un pc pas fait pour, et qui figeait régulièrement du coup - alors qu'aujourd'hui, si j'ai bien compris, avec assez d'espace disque, il suffit de tout installer par snap, et hop'!, plus d'interférences ^^)

# et le fait qu'un support soit connecté à /media/USER, c'est une sécurité pour ne pas qu'un autre utilisateur puisse déconnecter le support sans l'accord de celui qui l'a monté ? - Plusieurs utilisateurs peuvent-ils utiliser un support monté par un seul d'entre eux...? #

Je retourne les résultats des commandes :

~$ echo -e "\nNombre d'éléments de /home/moi ne m'appartenant pas : $(sudo find ~ \( ! -user $USER -o ! -group $USER \) | wc -l)"
[sudo] Mot de passe de anotherway : 

Nombre d'éléments de /home/moi ne m'appartenant pas : 89

~$ find ~ -name ".*" ! -user $USER -exec sudo ls -l {} \;
find: ‘/home/anotherway/.config/xarchiver’: Permission non accordée
find: ‘/home/anotherway/.cache/dconf’: Permission non accordée
find: ‘/home/anotherway/.cache/doc’: Permission non accordée
find: ‘/home/anotherway/.cache/gvfs-burn’: Permission non accordée
find: ‘/home/anotherway/.cache/gnome-shell’: Permission non accordée
total 0
find: ‘/home/anotherway/.gvfs’: Permission non accordée

~$ find ~ -name ".*" ! -user $USER -exec sudo chown -Rc $USER:$USER {} \;
find: ‘/home/anotherway/.config/xarchiver’: Permission non accordée
find: ‘/home/anotherway/.cache/dconf’: Permission non accordée
find: ‘/home/anotherway/.cache/doc’: Permission non accordée
find: ‘/home/anotherway/.cache/gvfs-burn’: Permission non accordée
find: ‘/home/anotherway/.cache/gnome-shell’: Permission non accordée
[sudo] Mot de passe de anotherway :
appartenance de '/home/anotherway/.gvfs' modifiée de root:root en anotherway:anotherway

~$ echo -e "\nNombre d'éléments de /home/moi ne m'appartenant pas : $(sudo find ~ \( ! -user $USER -o ! -group $USER \) | wc -l)"

Nombre d'éléments de /home/moi ne m'appartenant pas : 88

(bon, on a récupéré .gvfs... ...en même temps, c'est un dossier vide... )

~$ find ~ -name ".*" ! -user $USER -exec sudo ls -l {} \;
find: ‘/home/anotherway/.config/xarchiver’: Permission non accordée
find: ‘/home/anotherway/.cache/dconf’: Permission non accordée
find: ‘/home/anotherway/.cache/doc’: Permission non accordée
find: ‘/home/anotherway/.cache/gvfs-burn’: Permission non accordée
find: ‘/home/anotherway/.cache/gnome-shell’: Permission non accordée

(Donc ça, ce serait du contenu qu'il serait normal qu'il n'appartienne qu'à root dans un HOME $USER)

J'ai visité le lien de Xubu1957, je vois des commandes "complémentaires"
(en fait, une, qui évolue) :
find ~ -xdev -iname \**\* -exec bash -c 'sudo chown -c $USER:$USER "{}"' \;

find ~ -xdev -name "*" -exec sudo chown -ch $USER:$USER "{}" \;

echo -e "\nNombre d'éléments de /home/moi ne m'appartenant pas : $(sudo find ~ $ ! -user $USER -o ! -group $USER $ | wc -l)"
(ils ont l'air de recommander cette dernière, est-ce que ce serait pertinent dans mon cas...?)

~$ sudo chown -c root:root {/media,/media/anotherway,/media/coucou}
appartenance de '/media' modifiée de coucou:vip en root:root
appartenance de '/media/anotherway' modifiée de coucou:vip en root:root
appartenance de '/media/coucou' modifiée de coucou:vip en root:root

~$ sudo chmod -c 755 /media

~$ sudo chmod -c 750 /media/anotherway
le mode de '/media/anotherway' a été modifié de 0777 (rwxrwxrwx) en 0750 (rwxr-x---)

Est-ce que (tous ports démontés), on ne ferait pas mieux de mettre le paramètre -R : "sudo chmod -Rc 750 /media/anotherway" ?
Lorsque je mets une nouvelle clé, je ne peux rien faire dessus (ni créer, coller, renommer, supprimer, ...),
alors je fais :

~$ sudo chmod -c 750 /media/anotherway/86E3-D486
[sudo] Mot de passe de anotherway : 
le mode de '/media/anotherway/86E3-D486' a été modifié de 0755 (rwxr-xr-x) en 0750 (rwxr-x---)

et là je peux utiliser cette nouvelle clé.
---
Je rappelle juste que ça fait trèèèèès longtemps que je n'avais pas touché à ce PC,
que tout ce passait bien avec son utilisateur jusqu'à présent (malgré le foutoir),
et que du coup, je ne sais pas... Est-ce que ce ne serait pas une MAJ qui aurait planté un truc...?

Côté utilisateur, ils peuvent accéder à leurs données... Si jamais je vois qu'il y a besoin de créer une session Admin, je le ferais, mais pour le moment, je pense que c'est bon... - Merci du conseil
---
Bon, je pense que ma clé initiale est cuite, même après tout ça, le problème persiste, pourtant, les fichiers qu'elle contient sont consultables, bizarre...
J'ai essayé un "sudo dosfsck" comme indiqué ici : https://www.madz.fr/blog/technique/comm … seule.html
rien à faire...
J'avais trouvé un vieux topic avec exactement le même problème que moi - impossible de le tretrouver...
---
Quant au message d'erreur lors du démontage, il reste,
ici, ils partaient sur une erreur de copie, puis finalement de thème avec GTK, bon...
https://forums.archlinux.fr/viewtopic.php?p=159176
---
En tous casa je vous remercie beaucoup pour votre temps & votre intérêt,
je pense qu'on arrive bientôt sur la fin du problème

Dernière modification par Tanguy, .L.J. (Le 15/03/2023, à 05:43)

MicP · Le 15/03/2023, à 06:32

Bonjour Tanguy, .L.J.

Donne nous plutôt des retour utilisables de commandes et surtout complets <=> avec l'intégralité des lignes retournées par la commande,
et pas seulement les lignes que tu penses êtres importantes.

Par exemple, dans le retour de commande ci-dessous,
il manque des lignes importantes, il manque aussi le prompt de retour,
et le prompt de départ affiché n'est sans doute pas celui qui apparaissait dans ta fenêtre de terminal.

Dans son message #9 , Tanguy, .L.J. a écrit :

~$ ls -la /media/$USER
drwxr-xr-x  2 anotherway anotherway  4096 janv.  1  1970 'ANOTHER WAY'

Dans le retour de commande ci-dessus, il manque au moins deux lignes
qui concernent les répertoires . et .., et du coup on ne peut pas savoir s'il existe bien, comme ça devrait être le cas,
des règles ACL pour ton répertoire /media/$USER qui aurait dû être listé, dans ce retour de commande, sous le nom . (<=> par un simple point)

Prends le temps de lire le fil de discussion qui est accessible par le lien que j'ai mis au début de ce message (et qui est aussi dans ma signature, en bas de chacun de mes messages),
tu comprendras sans doute mieux l'importance que ces informations manquantes apportent pour mieux comprendre le contexte
dont dépend le retour de la très très grande majorité des lignes de commandes entrées.

=======
D'autre part, si tu veux t'amuser sans risque à bricoler tout ce que tu veux sur un système,
et pouvoir revenir en arrière (retrouver le système dans l'état où il était juste avant d'avoir lancé une commande qui l'aurait bloqué)
utilise des machines virtuelles (Qemu/Kvm ou VirtualBox) et tu apprécieras beaucoup le confort des snapshots (en français, c'est parfois traduit par Instantanés)

Dernière modification par MicP (Le 15/03/2023, à 06:35)

xubu1957 · Le 15/03/2023, à 08:16

Bonjour,

Lecture conseillée > memento des balises code.

Coeur Noir · Le 16/03/2023, à 03:33

J'aimerais quand même savoir à qui appartiennent les éléments incriminés… Essaie à nouveau, cette fois :

sudo find ~ -name ".*" ! -user $USER -exec sudo ls -l {} \;

Au #11 et au #8 tu as des explications, illustrations et des liens vers des doc's → (re)lis-les.

Notamment, ce que te demande MicP à propos des retours de commandes… déjà demandé à la fin du #8.
Et ce qui concerne les droits et permissions puisque ça a l'air de t'intriguer voire t'échapper complètement.

Il y a aussi un certain nombre de questions auxquelles tu ne donnes pas réponse ( sur le contexte, l'histoire de ta machine, comment elle a été mise à niveau ou à jour… )
ou si tu as testé tes supports~clés ailleurs ?

As-tu compris pourquoi il est capital que les éléments cachés dans un $HOME appartiennent bien au titulaire de ce $HOME ?
Dans l'absolu c'est tous les éléments d'un $HOME qui appartiennent à son titulaire mais dans certains contextes c'est tolérable que des éléments visibles ne lui appartiennent pas directement ( si des droits lui sont accordés à travers un groupe propriétaire dont il est membre, par ex. )

Plusieurs utilisateurs peuvent-ils utiliser un support monté par un seul d'entre eux...?

S'il s'agit d'un support amovible~nomade qui fait l'objet d'un montage automatique → non,
même si ces « plusieurs utilisateurs » sont membres du groupe de l'utilisateur qui a branché le périphérique dans sa session, ils n'auront pas d'accès à /media/<autre_user>/périphérique> ils seront déjà bloqués à ce niveau là :
⋅ le dossier <autre_user> appartient à root:root avec droits rwxr-x--- ;
⋅ des permissions via ACL sur ce dossier n'en permettent l'accès qu'à l'$USER pour qui le système a activé ce montage, ces ACL sont induites par udisks et usdisksctl ( responsables du montages automatique de supports amovibles~nomades ) ;
⋅ tant que ce support est monté.

Pour le rendre accessible à une autre session ( sans débrancher le support ) il faudra d'abord « démonter » le système de fichiers ( démonter, pas éjecter ).
Puis te rendre dans l'autre session, sans nécessité d'arrêter la session en cours.
OU :
quitter la session ( et pas seulement changer d'utilisateur ) : quitter, arrêter la session d'un utilisateur « démonte » ce que le système a automatiquement monté pour l'utilisateur de cette session.

Si tu as besoin qu'un support amovible~nomade soit accessible par plusieurs utilisateurs depuis plusieurs sessions actives en même temps, il faudra en gérer manuellement le montage,
avec les pilotes et options adéquates s'il s'agit d'un système de fichiers qui ne gèrent pas les droit et permissions ( ntfs, fat… ) ou avec des droits et permissions adéquates « dans » ce support s'il s'agit d'un système de fichiers natif Linux.
Le point de montage devra accorder le droit de lecture à tous ( ou à minima au groupe des utilisateurs devant accéder aux données contenues ) :
⋅ les attributs par défaut d'un point de montage de partition sont root:root avec rwxr-xr-x ; soit le monde entier peut lire dans ce point de montage ;
⋅ on peut souhaiter restreindre l'accès à root:un_groupe avec rwxr-x--- ; soit seul l'utilisateur root et les utilisateurs membres de un_groupe peuvent lire dans ce point de montage.

Si jamais je vois qu'il y a besoin de créer une session Admin, je le ferais, mais pour le moment, je pense que c'est bon

J'ai envie de te dire « arrête de penser ». Car tu penses de travers, et agis pareil.
Les droits corrompus sur /media, /media/$USER et dans ton $HOME ne sont imputables qu'à des actions de ta part.
Pas au système lui-même, ni à des mises à jour.

L'idée derrière « créer » une nouvelle session - et à minima après avoir obligatoirement réparé /media et /media/$USER - c'est d'avoir un point de comparaison :
que se passe-t-il dans cette session neuve, sans passif, sans scories d'anciens $HOME, lorsque tu y branches des supports amovibles~nomades ?

Est-ce que (tous ports démontés), on ne ferait pas mieux de mettre le paramètre -R : "sudo chmod -Rc 750 /media/anotherway" ?

Non. Re-re-lis comment fonctionnent les dossiers /media et /media/$USER et le mécanisme de montage automatique de supports amovibles~nomades.
Ils existent justement pour que l'utilisateur n'ait pas à faire ce genre de manip's ; hasardeuses quand on ne maîtrise pas la question des droits et permissions, ou de l'authentification des utilisateurs ( laisse polkit tranquille. )
Si tu veux jouer avec les « profondeurs du système », MicP conseille des machines virtuelles comme terrain de jeu, et c'est fort judicieux : si à force de bidouilles tu « t'enfermes » dehors, bah tu supprimes la VM cassée puis t'en fais une autre…

Lorsque je mets une nouvelle clé, je ne peux rien faire dessus (ni créer, coller, renommer, supprimer, ...)

À ce moment là, il faudrait comprendre pourquoi… et non à l'aveugle changer des attributs.
Par exemple en en sachant plus sur cette clé, à ce moment-là : type de système de fichiers qu'elle héberge, droits qu'il accorde, ou n'accorde pas…

ls -la /media/$USER
mount | grep ^/dev

…car en temps normal, c.à.d quand les droits de $HOME et /media, /media/$USER sont sains, il y a des « astuces » selon les types de système de fichiers hébergés.

Dans le cas système de fichiers compatibles Linux, les éléments ( fichiers, dossiers ) portent eux-mêmes des attributs ( utilisateur + groupe propriétaires, droits, etc ) qui déterminent qui a le droit de faire quoi DANS cet élément.
Le DANS est important. À partir du moment où DANS le système de fichiers tu as un élément qui appartient à untel avec droits rwx------ alors seul untel fait tout ce qu'il veut DANS cet élément.

Comme le dossier~point~de~montage du système de fichiers appartient à root:root, seul root peut écrire~modifier à la racine de ce système de fichiers monté.

root peut donc fabriquer là un dossier « trucs », y attribuer des propriétaires ( utilisateur + groupe anotherway par ex ) et à minima un mode 700 : dès lors anotherway saura écrire dans « trucs », dossier dans cette clé, mais pas à côté, pas ailleurs. Et anotherway ne saura pas effacer « trucs » ( bien qu'il en soit propriétaire ) car seul root sait écrire~modifier dans le point~de~montage ( qui contient « trucs » ). C'est un intérêt « opérationnel » d'un point de montage appartenant à root : ça protège les éléments à la racine du système de fichiers monté, d'un effacement maladroit. Et c'est d'ailleurs comme ça qu'est organisé le dossier /home qui contient les $HOME…

alors je fais :

~$ sudo chmod -c 750 /media/anotherway/86E3-D486
[sudo] Mot de passe de anotherway : 
le mode de '/media/anotherway/86E3-D486' a été modifié de 0755 (rwxr-xr-x) en 0750 (rwxr-x---)

…peux-tu expliquer ce que tu penses avoir solutionné avec ce changement de mode ? ? ?
Indice : rien qui serait de nature à donner le moindre droit supplémentaire à anotherway ou qui que ce soit d'autre.

C'est intrigant quand même que ce changement de mode t'ait semblé améliorer ton sort, d'où les demandes de ls et mount un peu au dessus et ajoutons :

grep -E :[0-9]{4}: /etc/passwd

qui ne montrera aucun mot de passe contrairement à ce que son nom pourrait suggérer, mais les noms et uid des utilisateurs « humains » dans ton système ;

cat /etc/group

pour voir les groupes, comme son nom l'indique.
Et cette fameuse clé branchée, à nouveau :

ls -lna /media/$USER

ajout de l'option n qui montre les uid/gid plutôt que les noms littéraux des propriétaires.

Bon, il faudrait déjà rétablir les droits conventionnels dans $HOME, but de la première commande « préparatoire » sudo find ~… qui devrait montrer du root:root je présume.

Dernière modification par Coeur Noir (Le 16/03/2023, à 04:52)

Tanguy, .L.J. · Le 23/03/2023, à 04:22

Bonjour et merci à tous d'avoir bien voulu m'aider,

J'ai effectivement négligé quelques points :

le retour du prompt,
je sens que ça commençais à en agacer certains, c'est pas le but recherché,
il est toujours le même, absolument rien d'exceptionnel, et il est toujours bien ré-apparu à chaque fin d'exécution de commandes passées :
anotherway@aw-pc:~$

Donc, pour l'ancienne clé (ANOTHER WAY) :

le retour de cette commande-ci, dont je pensais que seule la ligne que j'avais indiquée suffisait (mes excuses).

anotherway@aw-pc:~$ ls -la /media/$USER
total 16
drwxr-x---+ 4 root       root       4096 mars  22 20:28  .
drwxr-xr-x  7 root       root       4096 mai   19  2017  ..
drwxr-xr-x  3 anotherway anotherway 4096 janv.  1  1970 'ANOTHER WAY'
drwxrwxrwx  2 coucou     vip        4096 janv.  4  2015  MultiKey
anotherway@aw-pc:~$

@Xubu1957 : J'aurais dû mettre le paragraphe dont tu parles en bloc de citation,
je n'avais pas mis les lignes dans les balises de code, puisque je ne les ai pas utilisées,
je comprends leur importance pour un retour,
maintenant pour une simple question, est-ce que ça va pas "encombrer" un peu...?

---

Vos réponses sont toujours enrichissantes,

dans mon cas,
- "coucou" est un utilisateur "invité" (oui, tien, j'aurais pu le nommer comme ça...), les utilisateurs sont donc distincts, et n'ont pas la nécessité d'échanger entre eux (j'avais dû créer un groupe vip à l'époque, pour des rigolades hors-VM, rien de spécifiquement important).
- pour qu'un périphérique amovible nomade soit accessible à tous (ntfs & fat effectivement - j'ai laissé les clés en fat32 - même pour les clés bootables il faut la laisser en fat32... ... ...oui, j'avais essayé de faire un multi-boot sur usb, en 2008 & 2010, je me suis vautré, ça marche plus facilement sur disque dur externe si on veut un multi-boot nomade. Depuis, je laisse les clés en fat32),
si je créée un utilisateur, il faudrait que je créée aussi un groupe, genre "invité", ainsi, si je décide que tous les utilisateurs ont tous les droits sur la clé, je les rattache à ce groupe.
(en fait, je créée un groupe "le-monde-entier", pour y rattacher des utilisateurs sélectionnés, et je ferme le robinet au vrai monde entier, grossomodo, c'est le principe...?)

Dans ces conditions, si tous les éléments d'un $HOME doivent appartenir à son propriétaire, pourquoi ne me suffirait-il pas de faire

sudo chmod -R rwXr-X--- ~

?

Après, oui, j'ai sûrement commis 2~3 erreurs, sans doutes, m'enfin j'insiste, le problème de clé est arrivé comme un cheveu sur la soupe, et ça fait des années que je n'avais pas même ouvert un terminal sur ce pc, et jusqu'ici tout allait bien (en tous cas en surface).
Bon, cette clé dysfonctionne aussi sur d'autres pc, les documents qu'elle contient sont consultables, les transferts de fichiers qui se font dessus se font en apparence, mais ne sont pas retenus d'une connexion à une autre, même en utilisant un navigateur de fichier ouvert avec gksudo, bon, elle doit être cuite...

---

Pour la nouvelle clé (86E3-D486) :

anotherway@aw-pc:~$ sudo find ~ -name ".*" ! -user $USER -exec sudo ls -l {} \;
anotherway@aw-pc:~$[sudo] Mot de passe de anotherway : 
anotherway@aw-pc:~$

anotherway@aw-pc:~$ ls -la /media/$USER
total 28
drwxr-x---+ 4 root       root        4096 mars  22 22:32 .
drwxr-xr-x  7 root       root        4096 mai   19  2017 ..
drwxr-xr-x  4 anotherway anotherway 16384 janv.  1  1970 86E3-D486
drwxrwxrwx  2 coucou     vip         4096 janv.  4  2015 MultiKey
anotherway@aw-pc:~$

anotherway@aw-pc:~$ mount | grep ^/dev
/dev/sda9 on / type ext4 (rw,relatime,errors=remount-ro,stripe=32639,data=ordered)
/dev/sda6 on /home type ext4 (rw,relatime,data=ordered)
/dev/fuse on /run/user/1000/doc type fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
/dev/sdc1 on /media/anotherway/86E3-D486 type vfat (rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2)
anotherway@aw-pc:~$

pourquoi ai-je l'impression que la seule ligne intéressante ici est celle de sdc1...? (qu'il met parfois en sdb1, d'une connexion à une autre...)

anotherway@aw-pc:~$ grep -E :[0-9]{4}: /etc/passwd
anotherway:x:1000:1000:Another Way,,,none:/home/anotherway:/bin/bash
coucou:x:1001:1002:coucou,,,:/home/coucou:/bin/bash
anotherway@aw-pc:~$

anotherway@aw-pc:~$ cat /etc/group
root:x:0:
daemon:x:1:
bin:x:2:
sys:x:3:
adm:x:4:syslog,anotherway
tty:x:5:
disk:x:6:
lp:x:7:
mail:x:8:
news:x:9:
uucp:x:10:
man:x:12:
proxy:x:13:
kmem:x:15:
dialout:x:20:
fax:x:21:
voice:x:22:
cdrom:x:24:anotherway
floppy:x:25:
tape:x:26:
sudo:x:27:anotherway
audio:x:29:pulse,timidity
dip:x:30:anotherway
www-data:x:33:
backup:x:34:
operator:x:37:
list:x:38:
irc:x:39:
src:x:40:
gnats:x:41:
shadow:x:42:
utmp:x:43:
video:x:44:
sasl:x:45:
plugdev:x:46:anotherway
staff:x:50:
games:x:60:
users:x:100:
nogroup:x:65534:
netdev:x:102:
crontab:x:103:
syslog:x:104:
fuse:x:105:
messagebus:x:106:
ssl-cert:x:107:
lpadmin:x:108:anotherway
scanner:x:109:saned
mlocate:x:110:
ssh:x:111:
utempter:x:112:
avahi-autoipd:x:113:
rtkit:x:114:
saned:x:115:
whoopsie:x:116:
avahi:x:117:
lightdm:x:118:
nopasswdlogin:x:119:coucou
bluetooth:x:120:
colord:x:121:
pulse:x:122:
pulse-access:x:123:
anotherway:x:1000:
sambashare:x:124:anotherway
gdm:x:125:
debian-spamd:x:126:
winbindd_priv:x:127:
coucou:x:1001:coucou
vboxusers:x:128:
vip:x:1002:coucou,anotherway
timidity:x:129:
guest-QMCL4X:x:130:
systemd-journal:x:131:
systemd-timesync:x:132:
systemd-network:x:133:
systemd-resolve:x:134:
uuidd:x:101:
input:x:136:
geoclue:x:137:
nm-openvpn:x:138:
clickpkg:x:139:
guest-rd1e0d:x:999:
clamav:x:140:
rdma:x:135:
postfix:x:141:
postdrop:x:142:
anotherway@aw-pc:~$

anotherway@aw-pc:~$ ls -lna /media/$USER
total 28
drwxr-x---+ 4    0    0  4096 mars  22 22:32 .
drwxr-xr-x  7    0    0  4096 mai   19  2017 ..
drwxr-xr-x  4 1000 1000 16384 janv.  1  1970 86E3-D486
drwxrwxrwx  2 1001 1002  4096 janv.  4  2015 MultiKey
anotherway@aw-pc:~$

Et tout a l'air de fonctionner normalement,
hors-mis le message d'erreur au démontage...

Mais, entre 2 connexions, tout bascule...
Et à présent, je n'ai plus le droit d'écrire dessus...

J'ai re-rentré les commandes précédentes, pour voir quelles sont les différences,
dans les droits, je n'en vois pas...

anotherway@aw-pc:~$ sudo find ~ -name ".*" ! -user $USER -exec sudo ls -l {} \;
anotherway@aw-pc:~$

anotherway@aw-pc:~$ ls -la /media/$USER
total 28
drwxr-x---+ 4 root       root        4096 mars  23 01:37 .
drwxr-xr-x  7 root       root        4096 mai   19  2017 ..
drwxr-xr-x  4 anotherway anotherway 16384 janv.  1  1970 86E3-D486
drwxrwxrwx  2 coucou     vip         4096 janv.  4  2015 MultiKey
anotherway@aw-pc:~$

anotherway@aw-pc:~$ mount | grep ^/dev
/dev/sda9 on / type ext4 (rw,relatime,errors=remount-ro,stripe=32639,data=ordered)
/dev/sda6 on /home type ext4 (rw,relatime,data=ordered)
/dev/fuse on /run/user/1000/doc type fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
/dev/sdc1 on /media/anotherway/86E3-D486 type vfat (rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2)
anotherway@aw-pc:~$

anotherway@aw-pc:~$ grep -E :[0-9]{4}: /etc/passwd
anotherway:x:1000:1000:Another Way,,,none:/home/anotherway:/bin/bash
coucou:x:1001:1002:coucou,,,:/home/coucou:/bin/bash
anotherway@aw-pc:~$

anotherway@aw-pc:~$ ls -lna /media/$USER
total 28
drwxr-x---+ 4    0    0  4096 mars  23 01:37 .
drwxr-xr-x  7    0    0  4096 mai   19  2017 ..
drwxr-xr-x  4 1000 1000 16384 janv.  1  1970 86E3-D486
drwxrwxrwx  2 1001 1002  4096 janv.  4  2015 MultiKey
anotherway@aw-pc:~$

Est-ce que ça peut venir de l'utilisation d'un port physique différent entre 2 connexions ?

...Oui, au milieu de toutes ces lignes, au bout d'un moment, je sais pas pourquoi, sur le moment ça m'avait paru intelligent, au point de le publier même, mais j'arrive effectivement à tenter des machins débiles et obtenir des résultas du genre :
"le mode de '/media/anotherway/86E3-D486' a été modifié de 0755 (rwxr-xr-x) en 0750 (rwxr-x---)"
(alors là, c'est le retour débile d'une ancienne commande tapée en état de fatigue, c'est pour ne pas "pourrir" la vue que je ne la mets pas entre les balises de code, parce que ça sert à rien...)

pourtant, graphiquement, je suis bien connecté dans la session anotherway,
d'après "ls" en terminal, les droits sont : propriétaire : anotherway, groupe : anotherway,
alors que dans Thunar, les propriétés du point de montage, les droits sont : propriétaire : root, groupe : root
(alors ça, c'est sensé être normal, puisque c'est un point de montage),
seulement à l'intérieur du coup, le problème c'est que anotherway ne peut plus que lire uniquement.

Et attention, c'est là que je suis totalement déboussolé, lorsque j'ouvre Thunar, avec gksudo thunar, je regarde les propriétés de ce point de montage :
propriétaire : Another Way, groupe : anotherway.

...et j'ai toujours le message d'erreur au démontage, remonté au début du topic...

Bon... Étant de toutes façons toujours sur Bionic, je pense que... je vais faire mes sauvegardes, hein, ... et puis passer directement sur Jammy...
J'attends encore un peu, m'enfin, c'est vraiment parce que j'ai pas envie que vos implications soient "vaines" (je pense avoir déjà compris quelques bonnes choses, ça c'est cool, c'est déjà génial).

Merci

Dernière modification par Tanguy, .L.J. (Le 23/03/2023, à 04:23)

iznobe · Le 23/03/2023, à 09:46

Bonjour ,

Tanguy a écrit :

j'ai fait un
sudo Thunar
(sur ma clé, 1ou2 dossiers, rien du système)

c' est exactement cela qu ' il ne faut pas faire que @Coeur Noir tente de t' expliquer .
le simple fait de mettre sudo dans une commande qui va lancer un programme en mode graphique : thunar ( avec des fenêtres qui s' affichent a l' ecran donc ) , fout en l' air les permissions des fichiers de configuration de ta partie utilisateur . meme si tu ne fais rien dedans .

bon , il lui faut 50 lignes , et du coup on s' y perd un peu . mais avec mon resumé , j' espere que tu comprends mieux là

Dernière modification par iznobe (Le 23/03/2023, à 09:53)

Coeur Noir · Le 23/03/2023, à 13:25

Iznobe :

Bon, cette clé dysfonctionne aussi sur d'autres pc, les documents qu'elle contient sont consultables, les transferts de fichiers qui se font dessus se font en apparence, mais ne sont pas retenus d'une connexion à une autre, même en utilisant un navigateur de fichier ouvert avec gksudo, bon, elle doit être cuite...

Tenter une réparation du système de fichiers de la clé avec fsck ?
Vérifier l'état de cette clé avec smartmontools ?

sdc1 c'est le support 86E3-D486, c'est la clé qui pose problème ?
Son montage et ses droits semblent conformes à un support externe traité automatiquement.

Je ne comprends pas qui est /media/$USER/MultiKey par contre ?
C'est un dossier vide créé manuellement dans /media/$USER ?
Si c'est le cas, et que rien n'est stocké ou monté dedans → à supprimer.
On ne se sert pas de /media/$USER manuellement, on le laisse à l'automatisme du système pour les données amovibles.

Je suis surpris que

sudo find ~ -name ".*" ! -user $USER -exec sudo ls -l {} \;

ne réponde rien. Essaie ( désolé pour les tâtonnements ) :

sudo find ~ ! -user $USER -exec sudo ls -l {} \;

dans cette liste éventuellement longue, ce sont les éléments cachés ( dont le nom commence par un . point ) qui m’intéressent.

En faisant cela :

sudo chmod -Rc rwXr-X--- ~

tu changes le mode, les droits ( ce que utilisateur, propriétaire et les autres ont le droit de faire dans $HOME ) tu ne changes pas les utilisateur et groupe propriétaires des éléments $HOME et son contenu.
( mais rwXr-X--- sont bien des droits recommandables dans un $HOME, sauf pour certains éléments cachés comme les clés ssh ou gnugpg… )

sudo chown -Rc $USER:$USER ~

pour modifier les proprios ( change owner )

Dernière modification par Coeur Noir (Le 23/03/2023, à 13:26)

iznobe · Le 23/03/2023, à 21:43

Bonsoir , je ne comprends pas l ' utilité de ta citation , en rapport au fait de passer :
sudo UnTrucGraphique que j' indique dans mon unique message de cette discussion .

----------------------------

Coeur Noir a écrit :

Je suis surpris que
sudo find ~ -name ".*" ! -user $USER -exec sudo ls -l {} \;
ne réponde rien. Essaie ( désolé pour les tâtonnements ) :
sudo find ~ ! -user $USER -exec sudo ls -l {} \;

Petit test en passant :

iznobe@iznobe-PC:~$ sudo find ~ -name ".*" ! -user $USER 
/home/iznobe/.test
iznobe@iznobe-PC:~$ sudo find ~ ! -user $USER -exec sudo ls -l {} \;
-rw-r--r-- 1 root root 6 mars  23 20:40 /home/iznobe/.test
iznobe@iznobe-PC:~$ sudo find ~ -name ".*" ! -user $USER -exec sudo ls -l {} \;
-rw-r--r-- 1 root root 6 mars  23 20:40 /home/iznobe/.test
iznobe@iznobe-PC:~$

si rien ne ressort , c' est que le demandeur a deja rectifié les permissions de ses fichiers .

Dernière modification par iznobe (Le 23/03/2023, à 21:47)

Coeur Noir · Le 23/03/2023, à 23:31

si rien ne ressort , c' est que le demandeur a deja rectifié les permissions de ses fichiers
Oui possible, mais je me demandais si le fait de chercher avec le critère -name ".*" ne risquait pas d'exclure de la liste un élément visible ( n'appartenant pas à l'$USER ) placé dans un dossier lui caché…
Et bingo :

django@ASGARD:~$ mkdir .test
django@ASGARD:~$ cd .test/
django@ASGARD:~/.test$ sudo touch test
[sudo] Mot de passe de django : 
django@ASGARD:~/.test$ sudo find ~ -name ".*" ! -user $USER -exec sudo ls -l {} \;
django@ASGARD:~/.test$ sudo find ~ ! -user $USER -exec sudo ls -l {} \;
-rw-rw-r-- 1 root maison 0 mars  23 22:18 /home/django/.test/test
django@ASGARD:~/.test$

…le première commande find ne renvoie rien puisque le nom du fichier n'appartenant pas à $USER ne commence pas par un . point.

La citation, c'est parce qu'au #16 il n'y a rien qui ( me ) saute aux yeux concernant les droits et permissions et qui confirmerait l'usage d'un sudo thunar ; d'autant que Tanguy évoque gksudo thunar.
Et le fait qu'il a du mal à écrire dans cette clé depuis une autre machine semble indiquer un problème « dans » la clé.

iznobe · Le 24/03/2023, à 00:03

Coeur Noir a écrit :

La citation, c'est parce qu'au #16 il n'y a rien qui ( me ) saute aux yeux concernant les droits et permissions et qui confirmerait l'usage d'un sudo thunar ; d'autant que Tanguy évoque gksudo thunar.

on n' a pas du tout lu ou compris la meme chose , gksudo thunar dans son message , est precédé d ' un verbe au conditionnel . il ne l' a donc pas fait mais " il aurait du " :

Tanguy a écrit :

oui, j'aurais dû utiliser gksudo, bon, le fstab, sera le seul point "système" que j'aurais osé toucher en root, et je ne l'ai pas refait depuis des années, jusqu'à ce WE, parce que, l'écriture sur la clé dysfonctionne, j'ai fait un sudo Thunar (sur ma clé, 1ou2 dossiers, rien du système)

-----------------------------

Coeur Noir a écrit :

Et le fait qu'il a du mal à écrire dans cette clé depuis une autre machine semble indiquer un problème « dans » la clé.

Tout a fait d' accord avec cela .

Dernière modification par iznobe (Le 24/03/2023, à 00:06)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 11/03/2023, à 18:49

Écriture des données sur le périphérique usb

#2 Le 11/03/2023, à 19:05

Re : Écriture des données sur le périphérique usb

#3 Le 11/03/2023, à 19:18

Re : Écriture des données sur le périphérique usb

#4 Le 11/03/2023, à 20:00

Re : Écriture des données sur le périphérique usb

#5 Le 11/03/2023, à 20:48

Re : Écriture des données sur le périphérique usb

#6 Le 11/03/2023, à 21:35

Re : Écriture des données sur le périphérique usb

#7 Le 11/03/2023, à 23:34

Re : Écriture des données sur le périphérique usb

#8 Le 12/03/2023, à 01:11

Re : Écriture des données sur le périphérique usb

#9 Le 13/03/2023, à 16:52

Re : Écriture des données sur le périphérique usb

#10 Le 13/03/2023, à 17:00

Re : Écriture des données sur le périphérique usb

#11 Le 14/03/2023, à 03:38

Re : Écriture des données sur le périphérique usb

#12 Le 15/03/2023, à 05:37

Re : Écriture des données sur le périphérique usb

#13 Le 15/03/2023, à 06:32

Re : Écriture des données sur le périphérique usb

#14 Le 15/03/2023, à 08:16

Re : Écriture des données sur le périphérique usb

#15 Le 16/03/2023, à 03:33

Re : Écriture des données sur le périphérique usb

#16 Le 23/03/2023, à 04:22

Re : Écriture des données sur le périphérique usb

#17 Le 23/03/2023, à 09:46

Re : Écriture des données sur le périphérique usb

#18 Le 23/03/2023, à 13:25

Re : Écriture des données sur le périphérique usb

#19 Le 23/03/2023, à 21:43

Re : Écriture des données sur le périphérique usb

#20 Le 23/03/2023, à 23:31

Re : Écriture des données sur le périphérique usb

#21 Le 24/03/2023, à 00:03

Re : Écriture des données sur le périphérique usb

Pied de page des forums