Clé USB non détectée

geole · Le 04/07/2021, à 13:23

Bonjour
Je ne suis pas certain que faire une commande chown soit une bonne réparation pour un support amovible.
Ce support a pu être utilisé avec un ordinateur ayant deux utilisateurs dont on se moque des noms.
Dire que tout appartient maintenant à l'utilisateur 1000 fonctionne pour cet ordinateur mais ne va pas résoudre le problème initial de l'autre ordinateur pour l'utilisateur 1001. alors chmod ????

moko138 · Le 14/08/2021, à 00:31

MicP a écrit :

(...) et par défaut, le contenu des systèmes de fichiers dont le point de montage serait dans l'arborescence ciblée ($HOME) ne seront pas traités par la commande chown (...)

D'où sors-tu ça ?

Chez moi, c'est FAUX. Et j'ai fait le test.
D'où l'utilité du

find -xdev

.

MicP a écrit :

Il suffit simplement d'utiliser la ligne de commande suivante :
sudo chown -Rc $USER:$USER $HOME

Cela, ça marche en général, mais c'est CATASTROPHIQUE dans le cas où d'autres systèmes de fichiers sont montés sous /home/$USER.
Par exemple, pense à une partition contenant les dossiers de Toto, de Titi, de Pupuce, plus un dossier de partage, plus le dossier /lost+found qui appartient à root...

moko138 · Le 14/08/2021, à 00:42

geole a écrit :

Bonjour
Je ne suis pas certain que faire une commande chown soit une bonne réparation pour un support amovible.
Ce support a pu être utilisé avec un ordinateur ayant deux utilisateurs dont on se moque des noms.
Dire que tout appartient maintenant à l'utilisateur 1000 fonctionne pour cet ordinateur mais ne va pas résoudre le problème initial de l'autre ordinateur pour l'utilisateur 1001. alors chmod ????

On ne cherchait plus, ici, à réparer un support amovible qui j'a jamais été visible.
On cherchait simplement à corriger la corruption du home de Laudelu.

... Et comme nous n'avons plus de nouvelles de lui depuis une cinquantaine de jours...

Dernière modification par moko138 (Le 14/08/2021, à 00:47)

Coeur Noir · Le 23/09/2021, à 16:10

Cela, ça marche en général, mais c'est CATASTROPHIQUE dans le cas où d'autres systèmes de fichiers sont montés sous /home/$USER.
Euh… si on monte des choses dans /home/$USER c'est qu'à la base on estime que ces choses sont censées appartenir à $USER non ?

Je dirais plutôt que la catastrophe c'est de monter sous /home/$USER quelque chose qui n'appartiendrait pas à cet $USER - si on fait bien attention à ça alors la simple commande sudo chown -R $USER:$USER /home/$USER ne devrait pas être problématique.

Si on doit monter quelque chose à l'attention de plusieurs utilisateurs, on peut très bien le faire sous /home mais en dehors des répertoires persos existants, genre /home/Dossier-pour-tel-groupe
assez idéal pour des Bibliothèques de musique ou vidéos partagées entre plusieurs utilisateurs.

edit : quant au dossier lost+found je m'interroge, lui ne sera-t-il pas « ré-approprié » par root le jour où root en a besoin ?

Dernière modification par Coeur Noir (Le 04/10/2021, à 11:17)

nany · Le 13/11/2021, à 09:38

moko138 a écrit :

Pour l'option "-h" de chown :
man chown
       -h, --no-dereference
modifier les liens symboliques au lieu des fichiers référencés
je ne suis pas convaincu de sa pertinence derrière
find ~ -xdev (...)
Si j'ai tort, merci de m'expliquer.

Un point de montage n’est pas un lien symbolique.
Et j’avais eu des erreurs lors de mes tests d’où l’ajout de l’option h.

moko138 a écrit :

MicP et nany, veuillez vous mettre d'accord sur une formulation et je me ferai une joie d'adopter votre amélioration !

D’accord avec MicP pour le sudo find, cela permet d’explorer tous les répertoires.
De plus, je pense que rechercher tous les noms doit rendre l’opération longue. Il vaudrait mieux faire la recherche seulement sur les fichiers n’appartenant pas à l’utilisateur.
Donc :

sudo find ~ -xdev \( ! -user $USER -o ! -group $USER \) -exec chown -ch $USER:$USER "{}" \;

xubu1957 · Le 13/11/2021, à 09:44

Bonjour,

@nany

Une remarque d'hier :

Le 12/11/2021, lool_lauris a écrit :

Salut,
xubu1957 a écrit :
moko138 a écrit :
Merci de montrer :
echo -e "\n\tNombre d'éléments de /home/moi ne m'appartenant pas :"; find ~ $ ! -user $USER -o ! -group $USER $ | wc -l
Elle est bien cette commande ; mais ce qui lui manque est la liste des dossiers et fichiers qui sont détectés.

> dans un fil d'entraide

nany · Le 13/11/2021, à 10:01

Oui, j’avais lu et c’est pour ça que j’ai posté ici.

Pour la commande informative, il vaudrait mieux exécuter la commande avec sudo (pour la même qu’expliqué dans mon message précédent)

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

Pour avoir la liste, il suffit d’enlever le pipe :

echo -e "\n\tListe des éléments de /home/moi ne m'appartenant pas :"; sudo find ~ \( ! -user $USER -o ! -group $USER \)

lool_lauris · Le 13/11/2021, à 10:38

Merci pour le complément d'infos sur les commandes permettant de trouver les éléments n'appartenant pas user.

MicP · Le 29/01/2022, à 07:37

[Humour]

Dans son message #21, moko138 a écrit :

… Pour corriger un home corrompu …

Il faut deux m au mot homme,
[/Humour]

ou alors, dans un système de fichier Linux,
il existe deux interprétations possibles de "un home" :

- le répertoire /home/
- le répertoire personnel d'un compte utilisateur (qui est un sous-répertoire du répertoire /home/)

Dernière modification par MicP (Le 29/01/2022, à 07:58)

xubu1957 · Le 29/01/2022, à 07:41

Bonjour,

@aux aidants

Vos conseils pour la question de Brunoche.

Merci.

moko138 · Le 29/06/2023, à 19:06

Salut Coeur Noir !

Coeur Noir a écrit :

Cela, ça marche en général, mais c'est CATASTROPHIQUE dans le cas où d'autres systèmes de fichiers sont montés sous /home/$USER.
Euh… si on monte des choses dans /home/$USER c'est qu'à la base on estime que ces choses sont censées appartenir à $USER non ?

Oublierais-tu qu'un DDE peut être partagé par plusieurs personnes ?
De toute façon, l'option -xdev...
- qui impose "PAS TOUCHE aux autres systèmes de fichiers !" -
...de find prévient ce souci.

Coeur Noir a écrit :

edit : quant au dossier lost+found je m'interroge, lui ne sera-t-il pas « ré-approprié » par root le jour où root en a besoin ?

Es-tu volontaire pour le crash test ?
Et de toute façon, l'option -xdev de find prévient ce souci. (bis)

Coeur Noir a écrit :

Je dirais plutôt que la catastrophe c'est de monter sous /home/$USER quelque chose qui n'appartiendrait pas à cet $USER - si on fait bien attention à ça alors la simple commande sudo chown -R $USER:$USER /home/$USER ne devrait pas être problématique.

Le problème apparu avec les snaps, c'est leur accès, souvent restreint à /home/§USER, restriction qui a poussé beaucoup de gens, et même de tutoriels, à monter ou faire monter les media de stockage dans /home/§USER.

Et de toute façon, l'option -xdev de find prévient ce souci. (ter)

Coeur Noir a écrit :

Si on doit monter quelque chose à l'attention de plusieurs utilisateurs, on peut très bien le faire sous /home mais en dehors des répertoires persos existants, genre /home/Dossier-pour-tel-groupe
assez idéal pour des Bibliothèques de musique ou vidéos partagées entre plusieurs utilisateurs.

Ingénieux mais l'utilisateur lambda ne le fera pas. (Et les snaps et appimages, auront-ils le droit d'y accéder ? C'est vous qui me le direz.)

moko138 · Le 29/06/2023, à 19:18

lool_lauris a écrit :

Merci pour le complément d'infos sur les commandes permettant de trouver les éléments n'appartenant pas user.

Salut lool_lauris !

C'est par discrétion envers la personne aidée que j'ai ajouté, il y a déjà longtemps, le

| wc -l

et le remède fonctionne sans divulguer les noms des éléments corrompus.
Donc, en dépannage, prudence !

Et bonne soirée à tous !

Coeur Noir · Le 30/06/2023, à 00:54

Un snap ( généralement ) :
⋅ accède à $HOME ( /home/$USER ) mais pas à /home
⋅ s'il est connecté à l'interface removable-media, alors il accède aussi à /media, /run/media et /mnt ( mais toujours pas à /home )
⋅ donc si on utilise snap il faut renoncer à effectuer des montages dans /home, à placer des dossiers~bibliothèques partagées sous /home mais on pourrait envisager des montages sous /home/$USER/<point_de_montage>
⋅ le plus simple, ce sera quand même d'utiliser /media/<point_de_montage> après tout il sert à ça ce dossier /media ( données amovibles non vitales pour le système. )

Si on monte quelque chose dans $HOME ( sous /home/$USER/ donc ) cette chose DEVRAIT exclusivement s'adresser et appartenir à cet $USER.
On peut faire autrement ( appartenance au groupe $USER ou autre groupe commun à plusieurs utilisateurs comme le 100, users ) mais comme par convention on s'attend à ce que tout appartienne à $USER:$USER sous $HOME, c'est prendre des risques lors de certaines opérations administratives. On est bien d'accord : autant ne pas conseiller de montages sous $HOME.

Là aussi, des montages sous /media/<point_de_montage> sont plus opportuns, c'est la fonction de ce dossier.

Et surtout pas de montages manuels sous /media/$USER/ → ce dossier quand il existe, on en laisse la pleine jouissance au système, pour les montages « à la volée, à chaud » de supports de données amovibles ( clé USB, DD externes, cartes mémoires, dvd… ) via udisks / udisksctl. Mais à froid, à la base, le dossier /media/$USER n'existe pas : il ne se crée que lors du branchement d'un support de données.
Donc précaution à prendre pour des montages manuels volontaires sous /media/ → leur donner un nom qui ne risque pas d'être confondu avec celui d'un utilisateur potentiel du système → il suffit d'utiliser au moins une majuscule.

Il ne faut jamais préjuger de la puissance créatrice de l'utilisateur lambda, avec ou sans préméditation.
D'autant que certains utilitaires graphiques emploieront par défaut /mnt/<uuid_ou_label> par défaut, sans rien dire ( pourtant ils permettent de faire autrement mais ça ne saute pas aux yeux. )
/mnt/ fait partie des dossiers accessibles par un snap lorsqu'il est connecté à l'interface removable-media.

Peut-on demander à find de « suivre » les liens symboliques ? ( intuition : risques de redondances infinies, en boucle, si liens mal fagotés… )
Perso, mes données visibles sont dans /media/DATA/moi/<dossiers_perso_usuels> et dans $HOME je n'ai que des liens symboliques vers eux.

django@ASGARD:~$ ls -l
total 0
lrwxrwxrwx 1 django django 34 mai   16 18:01 Bureau -> /media/USERS-DATA/coeurnoir/Bureau
lrwxrwxrwx 1 django django 37 mai   16 18:01 Documents -> /media/USERS-DATA/coeurnoir/Documents
lrwxrwxrwx 1 django django 34 mai   16 18:01 Images -> /media/USERS-DATA/coeurnoir/Images
lrwxrwxrwx 1 django django 36 mai   16 18:01 Modèles -> /media/USERS-DATA/coeurnoir/Modèles
lrwxrwxrwx 1 django django 54 mai   16 19:39 Musique -> '/media/USERS-DATA/Bibliothèque Musicale/Bibliothèque'
lrwxrwxrwx 1 django django 45 mai   16 18:01 Téléchargements -> /media/USERS-DATA/coeurnoir/Téléchargements
lrwxrwxrwx 1 django django 35 mai   16 18:01 Vidéos -> /media/USERS-DATA/coeurnoir/Vidéos

Si je fais

find ~/Images -type f -iname *.jpg

il ne me répondra rien.
Par contre si je fais

find /media/DATA-USERS/coeurnoir/Images -type f -iname *.jpg

là oui, y'a du monde ;-)
Le sachant c'est pas bloquant, mais la première fois j'ai eu un peu peur

Je note pour -xdev mais dans mon cas c'est plutôt contre-productif, je crois.

Dernière modification par Coeur Noir (Le 30/06/2023, à 01:00)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#26 Le 04/07/2021, à 13:23

Re : Clé USB non détectée

#27 Le 14/08/2021, à 00:31

Re : Clé USB non détectée

#28 Le 14/08/2021, à 00:42

Re : Clé USB non détectée

#29 Le 23/09/2021, à 16:10

Re : Clé USB non détectée

#30 Le 13/11/2021, à 09:38

Re : Clé USB non détectée

#31 Le 13/11/2021, à 09:44

Re : Clé USB non détectée

#32 Le 13/11/2021, à 10:01

Re : Clé USB non détectée

#33 Le 13/11/2021, à 10:38

Re : Clé USB non détectée

#34 Le 29/01/2022, à 07:37

Re : Clé USB non détectée

#35 Le 29/01/2022, à 07:41

Re : Clé USB non détectée

#36 Le 29/06/2023, à 19:06

Re : Clé USB non détectée

#37 Le 29/06/2023, à 19:18

Re : Clé USB non détectée

#38 Le 30/06/2023, à 00:54

Re : Clé USB non détectée

Pied de page des forums