[RÉSOLU] Sauvegarde sûre avant ré-installation : PC très très lent

theyoubot · Le 27/02/2022, à 00:50

La sauvegarde via l'interface graphique a réussi :

Ci dessus, mon répertoire de fichiers persos (910 Go de textes, images, films) appelé BIBLIO, copié sur mon disque dur externe Toshiba.
Vos conseils précieux sur les petits nettoyages de l'OS et le port USB 3 ont rendu cette copie plus rapide. Merci à vous tous.

Pourquoi j'ai un répertoire lost+found dans mon disque dur externe (après l'avoir passé en EXT4) ?

Coeur Noir a écrit :

On peut juste se demander pourquoi utiliser Ubuntu si c'est pour en changer l'explorateur de fichiers par défaut, alors qu'une variante « officielle » propose Nemo.
Sinon il y a aussi une variante ×buntu « non-officielle » Ubuntu Cinnamon qui propose le même environnement que Mint, Nemo inclus

En 2013, Ubuntu a enlevé à Nautilus l'affichage en vue compacte et la mémorisation du mode d'affichage de chaque répertoire. Deux fonctionnalités cruciales pour moi. Impossible de travailler avec ce nautilus 3.6. Donc je me suis arrangé pour retourner sous Nautilus 3.4. Pendant 9 ans, jusqu'à aujourd'hui, j'y suis 'resté'.
En 2014, j'ai du recourir à un premier fork de Nautilus 3.4, installable sous ubuntu. C'était Nemo 1.8.4. Puis un deuxième etc. Les noms des forks ont changé mais pas les fonctionnalités.
Chemin faisant, j'ai appris que Nemo faisait carrière chez Cinnamon. Mais pour moi, Nemo n'était à l'origine que Nautilus 3.4, le gestionnaire d'ubuntu. Je ne voyais donc pas de raison d'utiliser mes forks de nautilus 3.4 sous autre chose qu'ubuntu.
Vers 2016 ou 2017, j'ai quand même regardé des démos de Cinnamon, par curiosité. J'avais découvert des carences problématiques du fork dans cet environnement.

Mais si Cinnamon m'avait satisfait, j'aurais changé de distri. Je travaillerai sous n'importe quel environnement optimal pour mon gestionnaire de fichiers, sa vue compacte et sa mémorisation du mode d'affichage de chaque répertoire. Ce gestionnaire de fichiers est la finalité de mon ordinateur, toute mon activité est bâtie autour de lui.

Je passe à la suite du plan.

1 - Création d'une clé 20.04, effacement minutieux de mon disque HDD

2 - Dépoussiérage (bombe à air comprimé), pâte thermique.

3 - Ajout de 4 Go RAM. Montage d'un SSD et install 20.04 sur le SSD

Puis j'étudierai ce message

_{Modération : merci d'utiliser des images de petite taille (300x300) ou des miniatures pointant sur ces images.}

Dernière modification par theyoubot (Le 27/02/2022, à 11:39)

Coeur Noir · Le 27/02/2022, à 01:32

Ce gestionnaire de fichiers est la finalité de mon ordinateur.
Je comprends tout à fait ça. L'explorateur de fichiers est un élément crucial.
Tu vas croire que je prêche pour une paroisse mais jette un œil à Nemo dans UbuntuBudgie, tu y trouveras les fonctions que tu évoques, par défaut sans besoin d'installer quoi que ce soit d'autre.
L'environnement de bureau Budgie est plutôt « simple », de base un panel en haut de l'écran, un dock centré en bas.
Mais il reste très configurable ( perso, je vire le dock et ajoute un panel à gauche ).
Dans chaque panel tu peux ajouter des « applets ».

Quelques « photos » d'une de mes install' de UBudgie ( après personnalisation, donc assez éloignée de son look par défaut ) :

…je l'utilise depuis quelques années, à la maison et au taf' donc si l'envie te prend de tester, n'hésite pas à me solliciter ;-)

Et idem au sujet de la partition DATA, ça pourrait faire l'objet d'une nouvelle discussion.

Dernière modification par Coeur Noir (Le 27/02/2022, à 03:44)

theyoubot · Le 27/02/2022, à 12:08

Coeur Noir a écrit :

Nemo dans UbuntuBudgie, tu y trouveras les fonctions que tu évoques

Dans ce cas, je te retourne la question : qu'est ce qui te fait croire qu'un fork de Nautilus 3.4 tourne mieux sous une autre distri qu'Ubuntu, ubuntu sous lequel Nautilus 3.4 est né ?

Coeur Noir a écrit :

L'environnement de bureau Budgie est plutôt « simple », de base un panel en haut de l'écran, un dock centré en bas. Mais il reste très configurable ( perso, je vire le dock et ajoute un panel à gauche )

Sous ubuntu, je ne change qu'une chose, la couleur de fond par défaut des fenêtres d'ubuntu, que je passe en gris clair. Mais sinon je n'ai rien à configurer dans mon gestionnaire de fichiers.

Coeur Noir a écrit :

si l'envie te prend de tester, n'hésite pas à me solliciter ;-)

Je pourrais me créer un clé Budgie 20.04 LTS (si c'est bien votre dernière version stable) et tester. Le prix à payer serait le temps d'apprentissage dans un environnement qui me serait moins familier que GNOME et les configurations auxquelles tu as fait allusion. Quel avantage à l'arrivée le justifierait ? Si c'est pour avoir la même chose, pourquoi m'embêter ?

Coeur Noir a écrit :

idem au sujet de la partition DATA, ça pourrait faire l'objet d'une nouvelle discussion.

J'aurais certainement besoin de tes lumières. Je créerai un sujet sur le forum.

Dernière modification par theyoubot (Le 27/02/2022, à 12:26)

Coeur Noir · Le 27/02/2022, à 14:39

Nautilus est fabriqué par Gnome, pour le bureau Gnome, pour bien s'y intégrer, et coller à « la vision » globale que les dév's ont de cet environnement de bureau.
Le Nautilus d'aujourd'hui est très différent du 3.4 d'hier ( il a « perdu » telle fonctionnalité, il a « gagné » telle autre ). Le bureau Gnome d'aujourd'hui est aussi très différent du bureau Gnome de l'époque de Nautilus 3.4.

Un fork x ou y de Nautilus est fabriqué par l'équipe de x ou y, pour le bureau x ou y, pour bien s'y intégrer, et coller à « la vision » globale que les dév's ont de cet environnement de bureau.
Il y a d'autres forks de Nautilus : Caja est « prévu » pour Mate, Nemo ( à la base ) pour Mint, (Pantheon)Files pour Elementary - liste ni exhaustive ni limitative.

Un explorateur de fichiers est un élément crucial d'un env. de bureau, à tel point qu'il est parfois très difficile de supprimer celui installé par défaut ( du moins pas sans perdre certaines fonctionnalités offertes par cet environnement ).

Après rien n'empêche d'installer un autre explorateur de fichiers en plus de celui par défaut. Mais en installer un autre à la place de celui par défaut ça sera plus difficile.

D'où « ma » suggestion : si ta priorité c'est d'utiliser Nemo, prends un env. de bureau où Nemo est déjà proprement installé par défaut. Maintenant si dans ton usage, utiliser un fork de Nautilus dans Gnome ne t'a jamais créé de pépins, ma foi, tant mieux ! Mais rien ne dit que tu y arriveras encore longtemps, vu les évolutions des logiciels ( le bureau Gnome + son explorateur de fichiers étant très liés ).

Quant à UBudgie, ça reste un env. Gtk fortement basé sur des utilitaires provenant de Gnome : tu y trouveras le même centre de contrôle pour les paramètres système ( gnome-control-center ), le même gestionnaire de connexions réseau ( network manager ), derrière c'est le même gestionnaire de fenêtres ( mutter ), etc…

Le prix à payer serait le temps d'apprentissage dans un environnement qui me serait moins familier que GNOME et les configurations auxquelles tu as fait allusion. Quel avantage à l'arrivée le justifierait ? Si c'est pour avoir la même chose, pourquoi m'embêter ?
Ou pourquoi s'embêter à installer Nemo ( ou autre ) dans Gnome/Ubuntu ?
Ça se trouve la config' par défaut de UBudgie te conviendrait dès le départ, donc zéro configuration autre à envisager.
Et tôt ou tard il faudra que tu apprennes les nouveautés introduites par l'évolution « naturelle » de Gnome/Ubuntu ( ou tout autre env. que tu utilises à long terme, aucun n'est complètement immuable ).
Enfin, c'est juste une proposition « libre », essayer en live-session sans rien installer définitivement, si ça te convient, tu installes, sinon tu choisis d'installer autre chose qui te plaît davantage…
Voire tu t'installes 2 systèmes côte à côte, en dual boot, puisque tes documents seront séparés des système, dans leur partition DATA qui plus est un disque distinct…

Dernière modification par Coeur Noir (Le 27/02/2022, à 21:17)

theyoubot · Le 27/02/2022, à 19:26

Tu m'as convaincu à 'ta priorité c'est d'utiliser Nemo, prends un env. de bureau où Nemo est déjà proprement installé par défaut'.
Budgie 20.04 LTS, c'est ça ? Et du coup comment ça va se passer en 2023 ? Y a une autre LTS pour prendre le relais ou je vais me retrouver orphelin ?

Dernière modification par theyoubot (Le 27/02/2022, à 19:34)

Coeur Noir · Le 27/02/2022, à 21:15

Les LTS pour Ubuntu et ses variantes officielles, y'en a une tous les deux ans.
La prochaine c'est donc en avril prochain.

La LTS d'Ubuntu/Gnome officielle est maintenue pendant 5 ans ( voire 10 sous conditions ) tandis que les variantes sont maintenues 3 ans ( du point vue environnement de bureau, autrement elles reçoivent les m.à.j de sécurité pendant 5 ans ).

Donc tu pourrais installer UBudgie 20.04 aujourd'hui puis mettre à niveau ( sans réinstaller ) vers la 22.04 en juillet/août prochain ( à la sortie de la 22.04.1 ), ou attendre jusqu'en mars 2023 pour passer à la 22.04.

Ou… faire une mise à niveau tous les 6 mois en suivant toutes les sorties intermédiaires ( 21.10 → 22.04 → 22.10 → 23.04 → etc ), celles-là ont 9 mois de support.

geole · Le 27/02/2022, à 21:31

Coeur Noir a écrit :

La LTS d'Ubuntu/Gnome officielle est maintenue pendant 5 ans ( voire 10 sous conditions ) .

Bonsoir.
A partir de le version 22.04 qui arrive dans deux mois maintenant, à chaque connexion on demandera de valider l'option 10 ans... Alors qu'avant, il fallait découvrir comment l'obtenir.
Nota. Il est malgré tout possible de refuser.

theyoubot · Le 28/02/2022, à 14:46

geole a écrit :

A partir de le version 22.04 qui arrive dans deux mois maintenant, à chaque connexion on demandera de valider l'option 10 ans

Ça peut m'intéresser. Car quand mon explorateur de fichiers tourne bien, je ne souhaite pas changer de version. J'ai toujours poussé mes LTS au maximum de leur espérance de vie.

Coeur Noir a écrit :

tu pourrais installer UBudgie 20.04 aujourd'hui puis mettre à niveau ( sans réinstaller ) vers la 22.04 en juillet/août prochain ( à la sortie de la 22.04.1 ), ou attendre jusqu'en mars 2023 pour passer à la 22.04.

Ok. Si Ubudgie convient, je resterai sous 20.04 jusqu'en 2023 puis passerai en 2023 à la 22.04.x stable du moment.

Dernière modification par theyoubot (Le 28/02/2022, à 14:48)

geole · Le 01/03/2022, à 15:03

Bonjour
Je me permets de reprendre cet échange https://forum.ubuntu-fr.org/viewtopic.p … #p22538325
en vue de le simplifier. Mes essais sont faits à partir de la version 22.04. Il faudra que je regarde si en 20.04, c'est pareil.

Exemple, avec le contexte suivant :
Un O.S. Ubuntu en 22.04 installé sur un disque entier et chiffré.
⋅ Une partition DATA, système de fichiers EXT4, contenant déjà des données. Probablement un cas fréquent.
⋅ Dans la session graphique d'un $USER, actions depuis un terminal placé dans son répertoire personnel ( situation par défaut à l'ouverture du terminal ).
1) Si besoin, lancement de gparted à installer pour mettre un point de montage DATA à la partition. Un autre nom (MesFichiers ?) peut être retenu. Il suffira d'en tenir compte dans la suite.
2) Création d'un point de montage dans le système pour la partition DATA

sudo mkdir /media/DATA
sudo chmod 777 /media/DATA

==> Ne pas oublier que l'outil officiel "DISQUE" (gnome-disks) choisit /mnt et non /media. Il faudrait probablement se mettre d'accord sur le premier niveau.
==> Ouvrir tous les droits va permettre la création automatique des poubelles et des utilisateurs.

3) Attacher cette partition DATA au système dès le démarrage, en ajoutant une ligne au fichier /etc/fstab ( après avoir sauvegardé l'actuel avant modification au cas où ) :

sudo   cp  -v  /etc/fstab   /etc/fstab_sauv_"$(date)"
echo LABEL=DATA  /media/DATA auto defaults 0 2 | sudo tee -a /etc/fstab

==> Mettre auto au lieu de EXT4 permet de ne pas imposer EXT4 au cas où on choisirait NTFS ou EXFAT. Tout cela pour un surcoût de quelques millisecondes au démarrage.

4) Activer maintenant les montages indiqués dans fstab par

sudo mount -va

5) Vérification optionnelle que tout fonctionne en utilisant un éditeur graphique, en créant un dossier et en le supprimant afin de voir que la corbeille fonctionne et est bien dédiée à l'utilisateur.

a@a:/media/DATA$ ls -als
total 12291633
      4 drwxrwxrwx 5 root root       4096 mars   1 12:54 .
      9 drwxr-xr-x 4 root root          4 mars   1 12:50 ..
      4 drwxr-xr-x 2 a    root       4096 mars   1 12:54 a
 233008 -rw-r--r-- 1 root root  238597848 févr. 23 15:08 bpool.gz
     16 drwx------ 2 root root      16384 févr. 23 11:07 lost+found
5936020 -rw-r--r-- 1 root root 6078480239 févr. 23 15:02 rpool.gz
6122568 -rw-r--r-- 1 root root 6269504628 févr. 23 15:14 rpool.raw
      4 drwx------ 4 a    a          4096 mars   1 12:54 .Trash-1000

a@a:/media/DATA$ ls -rls .Trash-1000
total 8
4 drwx------ 2 a a 4096 mars   1 12:54 info
4 drwx------ 3 a a 4096 mars   1 12:54 files
a@a:/media/DATA$ ls -Rls .Trash-1000
.Trash-1000:
total 8
4 drwx------ 3 a a 4096 mars   1 12:54 files
4 drwx------ 2 a a 4096 mars   1 12:54 info

.Trash-1000/files:
total 4
4 drwxrwxr-x 2 a a 4096 mars   1 12:35 mondossier

.Trash-1000/files/mondossier:
total 0
0 -rw-rw-r-- 1 a a 0 mars   1 12:35 titi

.Trash-1000/info:
total 4
4 -rw------- 1 a a 64 mars   1 12:54 mondossier.trashinfo

6) Chaque utilisateur devient responsable du déplacement des répertoires classiques

mkdir /media/DATA/$USER

7) Déplacer dans ce dossier nouvellement créé, les affaires stockées dans les dossiers usuels de /home/$USER :

 mv  -v  {Documents,Images,Modèles,Musique,Public,Téléchargements,Vidéos}   /media/DATA/$USER

8) Dans /home/$USER créer des liens symboliques qui ciblent les dossiers usuels de l'utilisateur désormais stockés dans la partition DATA :

ln   -s   /media/DATA/$USER/{Documents,Images,Modèles,Musique,Public,Téléchargements,Vidéos}  .

Surtout ne pas oublier le . sinon rien n'est créé.
Les logiciels graphiques et les commandes prennent immédiatement en compte la modification.

9) Le déplacement du bureau est aussi possible. C'est à faire immédiatement après une connexion afin que seuls les outils graphiques standards soient en oeuvre, il faut le faire en une seule ligne de commande qui est la suivante.

mv  -v   Bureau   /media/DATA/Bureau ;  ln -s /media/DATA/Bureau .

→ la commande mv déplace des éléments sans les modifier ( droits et permissions… )
Elle ne peut être utilisée qu'une fois. Les fois suivantes

cp  -iuv  {Documents,Images,Modèles,Musique,Public,Téléchargements,Vidéos}   /media/DATA/$USER
rm -riv {Documents,Images,Modèles,Musique,Public,Téléchargements,Vidéos}

→ $USER a le droit d'écrire, modifier, supprimer des éléments dans les dossiers {Documents,Images,Modèles,Musique,Public,Téléchargements,Vidéos} et de les supprimer s'il le souhaite puisque ces dossiers lui appartiennent comme il peut le faire lorsqu'il n'y a pas de liens symboliques.
→ un lien symbolique est un transfert de l'élément qu'il cible ( type, droits et permissions… ) il agit comme lui.
→ supprimer un lien n'en supprime pas la cible ; supprimer ou déplacer la cible casse le lien ( qui reste cependant en place, c'est un fichier ) ; replacer ou recréer l'élément cible restaure le lien.
→ Les corbeilles ne sont pas utilisées par les commandes rm . Il faut supprimer par l'interface graphique. La première suppression fabrique la corbeille.
À partir de maintenant l'$USER n'a plus qu'à ranger toutes ses affaires parmi ces dossiers usuels qui, physiquement sont stockés dans la partition DATA ( et non plus dans la partition racine / du système où continue de se trouver /home/$USER avec dedans principalement ses fichiers et dossiers cachés de param/config's + le dossier snap ).

Oui, ça signifie que ~/snap eux stockent toujours leurs données dans la partition racine / du système ( et pas du tout dans la partition DATA ).

C'est une organisation volontairement figée car
⋅ conserve pour l'utilisateur comme le système ou les applications, les chemins usuels dédiés aux affaires personnelles de l'humain,
⋅ dispense complètement l'utilisateur « normal » de naviguer directement dans /media/DATA/$USER puisque c'est justement le but des liens symboliques dans son rép. personnel !

Évidemment rien n'empêche d'ajouter d'autres dossiers, en plus, à côté des usuels dans /media/DATA/$USER puis d'y accéder via un lien symbolique dans le rép. perso :
à faire depuis un terminal placé dans le rép. personnel de l'$USER
⋅ création d'un nouveau dossier :

 mkdir /media/DATA/$USER/my_new_folder

⋅ création du lien dans /home/$USER :

ln -s /media/DATA/$USER/my_new_folder LeNouveauNom

Dernière modification par geole (Le 02/03/2022, à 17:33)

Coeur Noir · Le 01/03/2022, à 15:24

sudo chmod 777 /media/DATA

NON ! Un chmod 777 donne au monde entier le droit d'écrire dans ce montage : ça n'est évidemment pas souhaitable.
Peu d'intérêt puisqu'il y aura DANS cette partition un dossier $USER appartenant à $USER dans lequel l'$USER mettra toutes ces affaires.
Cela dit ça permet la création de la corbeille automatiquement, donc une fois qu'on a constaté que la corbeille fonctionne :

sudo chmod 755 /media/DATA

755 est suffisant ( root peut écrire, tous les autres peuvent lire ).

==> Mettre auto au lieu de EXT4 permet de ne pas imposer EXT4 au cas où on choisirait NTFS ou EXFAT. Tout cela pour un surcoût de quelques millisecondes au démarrage.
Parce que tu changes le format d'un système de fichiers à la volée peut-être ?
Si cette partition à monter est en EXT4, on indique ext4. Si on n'en connaît pas le format du système de fichiers on met auto.

→ la commande mv déplace des éléments sans les modifier ( droits et permissions… )
Elle ne peut être utilisée qu'une fois. Les fois suivantes

cp  -iuv  {Documents,Images,Modèles,Musique,Public,Téléchargements,Vidéos}   /media/DATA/$USER
rm -riv {Documents,Images,Modèles,Musique,Public,Téléchargements,Vidéos}

Euh… bah oui, qu'une seule fois, c'est un déplacement. Une fois qu'il est fait, ben il est fait…
Qu'est-ce que tu crois que la commande va copier si tu as déjà déplacé les dossiers ?
Il n'y a pas de « fois suivantes ».
Imagine qu'entre temps tu crées les liens : la copie échouera ( ça revient à copier un élément sur lui-même ) et l'effacement rm supprimera les liens ( sans toutefois supprimer leurs cibles, ouf ).
Et utiliser cp - selon l'utilisateur qui lance la commande - ça attribuera les éléments copiés à destination à cet utilisateur là : pas forcément ce qu'on veut, selon le contexte.

Attention au dossier bureau : tu as pu le déplacer parce que tu es sous Ubuntu/Gnome 22.04 où il n'est pas forcément « utilisé » graphiquement ( ça doit être pareil sous une Gnome 20.04 d'ailleurs ).
Ça ne sera pas le cas sous une Budgie ( et autres environnements ) où c'est généralement directement l'explorateur de fichiers graphique qui gèrent l'affichage du bureau sur l'écran.

Dernière modification par Coeur Noir (Le 01/03/2022, à 15:49)

geole · Le 02/03/2022, à 17:09

Bonjour
Quelques compléments d'information.
sudo chmod 777 /media/DATA
Le monde entier me semble un peu sinon sacrément exagéré. Cela sera certainement une personne utilisant l'ordinateur.
Alors chmod 775 va obliger à définir un chef qui a le droit à tout et doit tout préparer à l'avance et des esclaves confinés dans leur petite bulle. Pourquoi pas.

La mise de auto
L'idée est d'avoir une commande unique dont le contenu n'est pas à adapter au choix du formatage de la partition EXT2, EXT4, FAT32, EXFAT, NTFS, BTRFS, ZFS et probablement d'autres cas. Mais je n'ai pas pensé à vérifier que auto fonctionne correctement pour tous les types de format.
Le seul cas de changement de type de partition que je connais est lorsque windows cesse d'être utilisé et que enfin la partition de données est reformatée.
Au formatage, on pensera à remettre le même label car c'est bien pratique, mais la modification du fichier /etc/fstab risque fort de passer à la trappe.

La commande mv
D'abord le cas que je n'avais pas pensé qui est possible car déjà vu de très nombreuses fois avec des commandes de type sed demandant la suppression de quelques lignes

mkdir test
mv test /mnt/DATA/b
mv test /mnt/DATA/b
mv: impossible d'évaluer 'test': Aucun fichier ou dossier de ce type

Il a enfin une réponse qui risque de ne pas le satisfaire. J'avais pensé que mettre l'option -v était suffisant pour montrer que l'action avait fonctionné..

 mv -v test1 /mnt/DATA/b
répertoire '/mnt/DATA/b/test1' créé
répertoire 'test1' supprimé

On se souvient que si l'action est faite rapidement après l'installation, tous les répertoires sont vides sauf modèles qui a 9 fichiers.
Puis l'autre paquet de commande peut se faire sans risque

 ln -s /mnt/DATA/b/test .
 ln -s /mnt/DATA/b/test .
ln: impossible de créer le lien symbolique './test': Le fichier existe

Il n'y a non plus de problème survient si les deux paquets sont lancés ensembles et rejoués.

mv test3 /mnt/DATA/b
ln -s /mnt/DATA/b/test3 .
mv test3 /mnt/DATA/b
ln -s /mnt/DATA/b/test3 .
mv: 'test3' et '/mnt/DATA/b/test3' identifient le même fichier
ln: impossible de créer le lien symbolique './test3': Le fichier existe

Le problème que j'évoque est le suivant:
L'utilisateur a fait une installation dans une partition et mis ses données dans une autre partition par ces commandes nv qu'il a trouvée très pratique.
Il a envie maintenant d'installer un second O.S. pour voir ce que cela donne ou remplacer son O.S. après avoir vérifié que le nouveau convient
Tout naturellement il va rejouer ces commandes mv , c'est ce que j'ai appelé la seconde fois.

 mv test3 /mnt/DATA/b
mv: échec de déplacement interpériphérique de 'test3' vers '/mnt/DATA/b/test3' ; impossible de supprimer la cible: Le dossier n'est pas vide

Ce qui est normal car au bout d'un certain temps, le répertoire a été utilisé.
Je souhaitais donc penser à ce futur problème en trouvant des commandes qui fonctionnent dans les deux cas pour ne pas avoir de procédures différentes.
Mais c'est peut-être un faux problème. Si le déplacement est fait immédiatement après l'installation, il n'y aurait problème que pour ce seul répertoire

ls -Hls Modèles
total 72
 0 -rw-r--r-- 1 b b     0 mars   2 15:57 'Empty File'
 8 -rw-r--r-- 1 b b  6836 mars   2 15:57 'LibreOffice Calc.ods'
 8 -rw-r--r-- 1 b b  7508 mars   2 15:57 'LibreOffice Draw.odg'
12 -rw-r--r-- 1 b b 12093 mars   2 15:57 'LibreOffice Impress.odp'
 8 -rw-r--r-- 1 b b  7668 mars   2 15:57 'LibreOffice Writer.odt'
 8 -rw-r--r-- 1 b b  4914 mars   2 15:57 'MS Excel.xlsx'
24 -rw-r--r-- 1 b b 21201 mars   2 15:57 'MS PowerPoint.pptx'
 4 -rw-r--r-- 1 b b  4036 mars   2 15:57 'MS Word.docx'
 0 -rw-r--r-- 1 b b     0 mars   2 15:57 'Text File.txt'

Le problème spécifique du répertoire Bureau pour les O.S. budgie

 echo $XDG_CURRENT_DESKTOP
Budgie:GNOME

b@a:~$ mv -v $HOME/Bureau  /mnt/DATA/b ; ln -s /mnt/DATA/b/Bureau .
répertoire '/mnt/DATA/b/Bureau' créé
copié '/home/b/Bureau/fich1' -> '/mnt/DATA/b/Bureau/fich1'
répertoire '/mnt/DATA/b/Bureau/DIR' créé
copié '/home/b/Bureau/DIR/fic2' -> '/mnt/DATA/b/Bureau/DIR/fic2'
'/home/b/Bureau/DIR/fic2' supprimé
répertoire '/home/b/Bureau/DIR' supprimé
'/home/b/Bureau/fich1' supprimé
répertoire '/home/b/Bureau' supprimé
b@a:~$ ls -als 
total 72

Comme je n'ai pas compris que qui n'allait pas fonctionner, je trouve que tout c'est bien passé pour le déplacement du bureau.
Mais pas pour l'installation.

La question sans réponse.
Dans le forum, on dit de monter dans /media, Mais l'outil disques monte dans /mnt, et je n'ai pas trouvé de bug signalant que c'était une erreur.

Dernière modification par geole (Le 02/03/2022, à 18:54)

iznobe · Le 02/03/2022, à 17:18

Bonjour ,
[HS]
aux aidants , vu que la page de la doc a propos de la maniere dont monter une partition de données semble complexe , pourquoi ne pas en creer une nouvelle qui serait , simplifier au minimum , en partant d ' un ordinateur tout beau tout neuf , comme dans ce cas-ci , et repertoriant toutes les etapes qui pourrait etre amelioré au fil du temps , vu que c' est tout de meme un sujet récurant depuis la sortie des disques SSD NVME . ca s ' applique souvent dans des ordis multi-disques et ca ferait couler moins d' encre dans les fils .
[/HS]

Coeur Noir · Le 02/03/2022, à 20:17

geole a écrit :

sudo chmod 777 /media/DATA
Le monde entier me semble un peu sinon sacrément exagéré. Cela sera certainement une personne utilisant l'ordinateur.
Alors chmod 775 va obliger à définir un chef qui a le droit à tout et doit tout préparer à l'avance et des esclaves confinés dans leur petite bulle. Pourquoi pas.

Cela sera n'importe quelle personne ayant accès à ce système localement ou à distance, potentiellement à l'insu de l'utilisateur habituel. C'est un problème de sécurité basique.

On ne met pas de dossier en 777 dans un système. Point barre. ( temporairement à la rigueur, et encore ).
Il en existe déjà un → /tmp → avec le bit t qui restreint la suppression d'un élément à son propriétaire uniquement.
( et du fait de sa nature multi-utilisateurs /tmp n'est pas accessible aux logiciels « confinés » genre snap ).

Le « chef » est déjà défini : c'est root.
Et le chef s'occupe de tout ce qui est matériel : disques, partitions, périphériques, etc.

Les utilisateurs, eux, s'occuperont de leurs données comme ils veulent, dès lors que le chef aura mis en place les droits et permissions adéquats sur les emplacements ( dossiers ) nécessaires.
Une fois que le chef a organisé les pièces de la maison, on n'a plus besoin de lui.

( pas le temps d'écrire plus, je reviendrai ).

Coeur Noir · Le 03/03/2022, à 02:40

geole a écrit :

La mise de auto
L'idée est d'avoir une commande unique dont le contenu n'est pas à adapter au choix du formatage de la partition EXT2, EXT4, FAT32, EXFAT, NTFS, BTRFS, ZFS et probablement d'autres cas. Mais je n'ai pas pensé à vérifier que auto fonctionne correctement pour tous les types de format.
Le seul cas de changement de type de partition que je connais est lorsque windows cesse d'être utilisé et que enfin la partition de données est reformatée.
Au formatage, on pensera à remettre le même label car c'est bien pratique, mais la modification du fichier /etc/fstab risque fort de passer à la trappe

Je comprends mieux l'objectif mais je crains que ce ne soit pas possible, à creuser.
Il faudra forcément revenir sur la ligne de montage dans fstab car il peut très bien y avoir eu des options passées à ce montage, spécifiques à un système de fichiers et pas un autre.
Donc si tu laisses auto à une ligne qui contenait des options spécifiques à NTFS alors que cette partition est devenue « autre chose » tu prends le risque que le montage bloque.
Surtout si par ailleurs on s'aperçoit que ces lignes avaient été écrites par gnome-disks, qui adore coller des options pas spécialement universelles…

geole a écrit :

La commande mv
D'abord le cas que je n'avais pas pensé qui est possible car déjà vu de très nombreuses fois avec des commandes de type sed demandant la suppression de quelques lignes
mkdir test
mv test /mnt/DATA/b
mv test /mnt/DATA/b
mv: impossible d'évaluer 'test': Aucun fichier ou dossier de ce type

Euh… la commande mv fait ce qu'elle dit, elle déplace.
Après la première mv le dossier test n'est plus là ( dans ~/ je suppose vu que tu ne montres pas l'invite du terminal )
donc à la deuxième mv passée depuis le même emplacement, fatalement elle te répond « je ne trouve pas test » normal tu l'as déplacé juste avant.
Je ne vois pas trop où tu veux en venir là.

geole a écrit :

Le problème que j'évoque est le suivant:
L'utilisateur a fait une installation dans une partition et mis ses données dans une autre partition par ces commandes nv qu'il a trouvée très pratique.
Il a envie maintenant d'installer un second O.S. pour voir ce que cela donne ou remplacer son O.S. après avoir vérifié que le nouveau convient
Tout naturellement il va rejouer ces commandes mv , c'est ce que j'ai appelé la seconde fois.

Donc là on se trouve dans un cas où l'utilisateur a déjà des données bien rangées dans la partition data.
Quand il installe un nouvel OS ( multi-boot ) ou réinstalle un autre à la place, il n'a pas à rejouer tout le scénario,
il doit juste virer de /home/$USER les dossiers visibles usuels ( vides puisque install' toute fraîche ) et mettre à leur place des liens vers les dossiers qui sont déjà bien rangés dans la partition data.
Il suffit juste que les éléments ( qu'il s'agisse de liens ou de dossiers ) dans le répertoire personnel portent les noms :
Bureau, Documents, Images, Modèles, Musique, Public, Vidéo et Téléchargements ( si on est dans un système en Français, bien sûr ).
car ces 8 noms là sont attendus par de nombreux logiciels ( norme XDG, freedesktop ).

Les systèmes se fiant aux uid/gid pour déterminer les propriétaires des données, dans les nouveaux OS créer les utilisateurs dans le même ordre ( celui créé lors de l'install' aura 1000 comme uid, il aura donc accès aux données qui portent l'uid 1000 dans la partition data ). Les noms peuvent différer, ça n'a pas tant d'importance mais par commodité garder les mêmes c'est plus simple.

geole a écrit :

il n'y aurait problème que pour ce seul répertoire

ls -Hls Modèles
total 72
 0 -rw-r--r-- 1 b b     0 mars   2 15:57 'Empty File'
(…)
 0 -rw-r--r-- 1 b b     0 mars   2 15:57 'Text File.txt'

Il y aura problème si tu tentes de déplacer ce dossier vers une destination qui contient déjà un dossier de même nom, avec le même contenu.
Et encore… si tu fais ça depuis l'explorateur de fichiers en graphique, ça te demanderait si tu veux fusionner / remplacer.
Et de toute façon si on est dans le même scénario que juste au dessus, il n'y a pas à déplacer ce dossier, il faut le supprimer.

geole a écrit :

Le problème spécifique du répertoire Bureau pour les O.S. budgie
 echo $XDG_CURRENT_DESKTOP
Budgie:GNOME
b@a:~$ mv -v $HOME/Bureau  /mnt/DATA/b ; ln -s /mnt/DATA/b/Bureau .
répertoire '/mnt/DATA/b/Bureau' créé
(…)
Comme je n'ai pas compris que qui n'allait pas fonctionner, je trouve que tout c'est bien passé pour le déplacement du bureau.

Question : ton env. de bureau était-il en mode « j'affiche le contenu du dossier bureau via des icônes à l'écran » ?
Je n'ai pas testé sous UBudgie 21.10 ni 22.04, mais en tout cas sous 20.04 ( et avec la plupart des env. de bureau ça n'est pas spécifique à Budgie ) tant qu'un dossier Bureau fait l'objet d'un affichage graphique à l'écran,
ça empêche son déplacement ou sa suppression. Tant mieux si ça devient moins contraignant mais ça m'étonne !

Dernière modification par Coeur Noir (Le 03/03/2022, à 03:24)

Coeur Noir · Le 03/03/2022, à 03:09

geole a écrit :

Dans le forum, on dit de monter dans /media, Mais l'outil disques monte dans /mnt, et je n'ai pas trouvé de bug signalant que c'était une erreur.

Ça n'est pas vraiment un bug puisque l'utilisateur peut tout à fait mettre autre chose que /mnt comme point de montage dans gnome-disks.
Si /mnt est un choix discutable pour du « permanent » ça n'est cependant pas un choix par défaut « mauvais » : après tout comment gnome-disks pourrait-il deviner ce que l'utilisateur fera de cette partition, le type ou la nature des données qu'il va y stocker ? Seul l'utilisateur peut le savoir, donc c'est à l'utilisateur d'imposer sa décision à gnome-disks en écrivant en toutes lettres le point de montage de son choix.

Donc si on va par là :
ouvrir gnome-disks pour y créer un montage permanent + écrire le chemin en toutes lettres + enlever les options inutiles ou les adapter
=
1⋅ prendra autant sinon plus de temps que de l'écrire directement dans fstab,
2⋅ implique d'en savoir autant à propos des montages et de leurs options, qu'on le fasse dans l'utilitaire graphique ou directement dans le fichier fstab.

Dans ce cas je ne vois pas trop l'intérêt de gnome-disks - qui est par ailleurs un bel outil ( je ne veux pas que tu crois que je le conspue systématiquement, je m'en sers parfois ).

Ça rejoint l'autre remarque à propos de fstab / auto : quand il s'agit de monter des partitions au démarrage du système, je ne vois pas trop comment « éviter » de manipuler fstab directement.
À moins de ne faire que des montages en espace utilisateur via udisksctl mount -b au démarrage de session… à creuser.

geole · Le 03/03/2022, à 11:37

Bonjour Coeur Noir
Je t'invite à faire une installation neuve dans une partition et jouer le scénario de la partition de données tel que décrit dans cet échange. Il n'y a pas de piège.
Puis à faire une autre installation neuve d'une autre version d'O.S ou du même dans une autre partition et décider de mettre tes données dans la même partition de données en utilisant les commandes MV, tu verrais alors le problème même sous budgie.
Astuce pour l'éviter: Que les répertoires déplacés soient vides. Donc exclure Modèles comme le fait bluc dans sa documentation.
En la relisant, j'ai vu qu'il ne propose pas un chmod mais un chown.

Afin d'éviter cette double installation, on peut la simuler de la façon suivante:
Situation actuelle

a@a:~$ ls -l Modèles
total 72
-rw-r--r-- 1 a a     0 mars   3 11:42 'Empty File'
-rw-r--r-- 1 a a  6836 mars   3 11:42 'LibreOffice Calc.ods'
-rw-r--r-- 1 a a  7508 mars   3 11:42 'LibreOffice Draw.odg'
-rw-r--r-- 1 a a 12093 mars   3 11:42 'LibreOffice Impress.odp'
-rw-r--r-- 1 a a  7668 mars   3 11:42 'LibreOffice Writer.odt'
-rw-r--r-- 1 a a  4914 mars   3 11:42 'MS Excel.xlsx'
-rw-r--r-- 1 a a 21201 mars   3 11:42 'MS PowerPoint.pptx'
-rw-r--r-- 1 a a  4036 mars   3 11:42 'MS Word.docx'
-rw-r--r-- 1 a a     0 mars   3 11:42 'Text File.txt'
a@a:~$

Exécution du déplacement

@a:~$
répertoire '/mnt/DATA/Modèles' créé
copié 'Modèles/Empty File' -> '/mnt/DATA/Modèles/Empty File'
copié 'Modèles/LibreOffice Calc.ods' -> '/mnt/DATA/Modèles/LibreOffice Calc.ods'
copié 'Modèles/LibreOffice Draw.odg' -> '/mnt/DATA/Modèles/LibreOffice Draw.odg'
copié 'Modèles/LibreOffice Impress.odp' -> '/mnt/DATA/Modèles/LibreOffice Impress.odp'
copié 'Modèles/LibreOffice Writer.odt' -> '/mnt/DATA/Modèles/LibreOffice Writer.odt'
copié 'Modèles/MS Excel.xlsx' -> '/mnt/DATA/Modèles/MS Excel.xlsx'
copié 'Modèles/MS PowerPoint.pptx' -> '/mnt/DATA/Modèles/MS PowerPoint.pptx'
copié 'Modèles/MS Word.docx' -> '/mnt/DATA/Modèles/MS Word.docx'
copié 'Modèles/Text File.txt' -> '/mnt/DATA/Modèles/Text File.txt'
'Modèles/MS Word.docx' supprimé
'Modèles/LibreOffice Draw.odg' supprimé
'Modèles/Empty File' supprimé
'Modèles/LibreOffice Calc.ods' supprimé
'Modèles/MS PowerPoint.pptx' supprimé
'Modèles/LibreOffice Writer.odt' supprimé
'Modèles/Text File.txt' supprimé
'Modèles/LibreOffice Impress.odp' supprimé
'Modèles/MS Excel.xlsx' supprimé
répertoire 'Modèles' supprimé
    0 lrwxrwxrwx 1 a    a          18 mars   3 11:57 Modèles -> /mnt/DATA/Modèles
a@a:~$

Tout est donc parfait.

Allons donc sur le second O.S. On est d'accord qu'il y a la même chose.

a@a:~$ ls -ls Modèles
total 72
 0 -rw-r--r-- 1 a a     0 mars   3 12:01 'Empty File'
 8 -rw-r--r-- 1 a a  6836 mars   3 12:01 'LibreOffice Calc.ods'
 8 -rw-r--r-- 1 a a  7508 mars   3 12:01 'LibreOffice Draw.odg'
12 -rw-r--r-- 1 a a 12093 mars   3 12:01 'LibreOffice Impress.odp'
 8 -rw-r--r-- 1 a a  7668 mars   3 12:01 'LibreOffice Writer.odt'
 8 -rw-r--r-- 1 a a  4914 mars   3 12:01 'MS Excel.xlsx'
24 -rw-r--r-- 1 a a 21201 mars   3 12:01 'MS PowerPoint.pptx'
 4 -rw-r--r-- 1 a a  4036 mars   3 12:01 'MS Word.docx'
 0 -rw-r--r-- 1 a a     0 mars   3 12:01 'Text File.txt'
a@a:~$

Mais en lançant la commande mv, on obtient ce résultat .

a@a:~$  mv -v Modèles /mnt/DATA && ln -s /mnt/DATA/Modèles . && ls -ls  |  grep Modèles
mv: échec de déplacement interpériphérique de 'Modèles' vers '/mnt/DATA/Modèles' ; impossible de supprimer la cible: Le dossier n'est pas vide
a@a:~$

Je note que si on ne fait pas immédiatement le mv, il est fort probable que le répertoire téléchargements se comporte pareil.
C'est pour cela que je crois qu'il serait mieux d'avoir des commandes compatibles dans les deux contextes, y compris si le déplacement se fait un peu plus tard avec des données présentes dans le répertoire. D'où l'idée de faire des commandes de copie et de suppression.
Voilà ce que je voulais dire.

Dernière modification par geole (Le 03/03/2022, à 12:13)

geole · Le 03/03/2022, à 12:25

Coeur Noir a écrit :

Question : ton env. de bureau était-il en mode « j'affiche le contenu du dossier bureau via des icônes à l'écran » ?
Je n'ai pas testé sous UBudgie 21.10 ni 22.04, mais en tout cas sous 20.04 ( et avec la plupart des env. de bureau ça n'est pas spécifique à Budgie ) tant qu'un dossier Bureau fait l'objet d'un affichage graphique à l'écran,
ça empêche son déplacement ou sa suppression. Tant mieux si ça devient moins contraignant mais ça m'étonne !

Tu me poses une question à laquelle je ne sais pas répondre
J'ai installé hier budgie puis je l'ai lancé.
Le bureau était donc tel que le concepteur avait souhaité qu'il soit avec plein de choses en noir.
et des icones masquées qu'il fallait aller débusquer en bas de l'écran et qui n'étaient pas spécialement immobiles . Cela me rappelle une mauvaise période ou c'était pareil avec ubuntu mais à gauche
Je fait une capture d'écran.
Capture de l'écran d'accueil https://zupimages.net/viewer.php?id=22/09/ty3u.png
Puis après avoir trouvé comment lancer l'application Fichiers Voici l'écran obtenu https://www.zupimages.net/viewer.php?id=22/09/41az.png
Et enfin, en cliquant sur le dossier Bureau https://www.zupimages.net/viewer.php?id=22/09/xeut.png

Ne pas oublier que, comme pour ubuntu, il faut faire en une ligne de commande car si on décompose en deux lignes, un répertoire bureau s'est refabriqué. Il me semble qu'il récupère alors les fichiers comme si c'était un lien physique qui s'était créé.

Mais voici d'abord celle de ubuntu https://zupimages.net/viewer.php?id=22/09/s43f.png
D'autre part, il ne devrait pas y avoir besoin de le personnaliser puisque c'est la version qui est la meilleure.....

Dernière modification par geole (Le 03/03/2022, à 13:12)

Coeur Noir · Le 03/03/2022, à 22:59

https://www.zupimages.net/up/22/09/ty3u.png → Sur le bureau il n'y a aucune icône.
En bas il y a un dock ( plank ) pour lancer des appli's.

C'est donc pour ça que tu as pu déplacer le dossier Bureau → il ne fait pas l'objet d'un affichage graphique.
J'ignorais que c'était dorénavant le cas par défaut sous Budgie.

Ça se change dans « paramètres du bureau budgie », section Bureau, activer Icônes du bureau.
Tous les trucs un peu marrants se trouvent dans ↑ paramètres du bureau.

geole · Le 07/03/2022, à 15:44

Coeur Noir a écrit :

C'est donc pour ça que tu as pu déplacer le dossier Bureau → il ne fait pas l'objet d'un affichage graphique.
J'ignorais que c'était dorénavant le cas par défaut sous Budgie.
Ça se change dans « paramètres du bureau budgie », section Bureau, activer Icônes du bureau.

J'ai fini par trouver comment faire. Il semble que cela soit devenu une application, car par les options paramètre on peut seulement choisir des images d'arrière plan.
Par l'application il y a un peu plus de choix. J'ai vu que "activer les icônes du bureau" est déjà validé.

Voici la capture d'écran
https://zupimages.net/viewer.php?id=22/10/87ty.png

Donc à priori, Je ne vais pas savoir me mettre dans le contexte qui ne fonctionne pas.
Mais on n'est pas obligé de tout déplacer pour avoir tout au même endroit: Dans la partition de partage en NTFS, il n'y a que cinq dossiers déplacés. On peut très bien faire une commande dédiée au bureau à lancer facultativement.

Bonne journée.

Nota. Cette version gère très mal mon touchpad et ma souris pour les copier/coller

Coeur Noir · Le 07/03/2022, à 18:11

Donc à priori, Je ne vais pas savoir me mettre dans le contexte qui ne fonctionne pas.
Tu veux dire que même avec la fonction « Icônes sur le bureau » activée, tu peux toujours déplacer aussi facilement le dossier ~/Bureau ?

…finalement ce serait presque une bonne nouvelle.

Cette version gère très mal mon touchpad et ma souris pour les copier/coller
Pardon tu l'auras sans doute déjà précisée mais c'est quelle version de Budgie que tu essaies là ?

geole · Le 07/03/2022, à 18:50

La fonction était activée lorsque j'ai ouvert le logiciel d'affichage. Elle devait devait donc l'être avant que je fasse la copie.
Donc je n'ai pas jugé nécessaire de recommencer l'essai.

C'était la version 21.10. Je ne le l'ai pas signalé dans la discussion.

Pour la souris et le touchpad, il y avait probablement du paramétrage à faire.
Hors sujet
quatre principes me guident
En premier Ne jamais proposer de déactiver le secure boot. Mais je ne l'impose pas. Ni n'impose le mot de passe lorsqu'il est sécurisé .
En second, L'utilisateur doit être responsable de son ordinateur et ne pas déléguer. Lorsqu'il me semble que l'intervention est dans domaine d'entreprise (Certains le disent clairement), je m'abtiens. Je n'impose pas une organisation multi-utilisateurs sans avoir demandé si ce cas pourrait se produire.
En troisième. Les supports USB non sécurisés ne méritent pas qu'on parle de propriétaire. Si l'accès est impossible, je propose au plus simple. Il m'arrive quelquefois de faire cette proposition pour support interne seulement à but diagnostic en remettant à plus tard la rectification.
En quatrième. Je considère, certainement à tort, que l 'utilisateur a des sauvegardes de ses données. Lorsque je pense que ma proposition est dangereuse. Je le lui signale et essaie de la rendre moins dangereuse. Mais pas si facile que cela dans certains cas.
Ajout.
En aucun cas, je n'impose mon organisation au demandeur. S'il a windows, je ne lui fait pas virer.
S'il n'a pas le répertoire home indépendant du logiciel, je ne lance pas un SOS.
Fin du hors sujet.

Dernière modification par geole (Le 07/03/2022, à 23:55)

Coeur Noir · Le 03/04/2022, à 03:31

Tardivement, car je n'avais pas vu ça :
Je t'invite à faire une installation neuve dans une partition et jouer le scénario de la partition de données tel que décrit dans cet échange. Il n'y a pas de piège.
Puis à faire une autre installation neuve d'une autre version d'O.S ou du même dans une autre partition et décider de mettre tes données dans la même partition de données en utilisant les commandes MV, tu verrais alors le problème même sous budgie.

Geole, ça fait des années que je pratique ainsi. Sur certaines machines j'ai eu jusqu'à 9 OS installés en multi-boot, juste pour le fun… Comme la partition DATA ne contient que des documents et médias ( et pas de de config's ou paramètres cachés spécifiques - ou seulement ceux dont je suis sûr du caractère immuable, agnostique ) ces données n'ont aucun impact sur le fonctionnement des systèmes. DATA peut même être absente, déconnectée, l'OS s'en fiche, il n'a pas besoin d'elle pour fonctionner. Et les utilisateurs dans tous ces OS peuvent toujours lancer leurs sessions graphiques puisque leurs $HOME sont restés sagement à la racine de chaque OS, avec leurs données cachées dédiées incluses, à leur place conventionnelle.

décider de mettre tes données dans la même partition de données en utilisant les commandes MV
⋅ S'il y a déjà des données à partager dans la partition DATA, il n'y a pas à déplacer quoi que ce soit. C'est un intérêt de cette partition : on y met les données visibles d'autant d'utilisateurs qu'on veut, et elles ne bougent jamais plus de là !
La seule chose à faire dans ce cas, c'est dans les $HOME ( à leur place conventionnelle ) mettre des liens symboliques en lieu et place des dossiers usuels, qui ciblent les données de tel utilisateur dans la partition DATA ( utilisateur qu'on repère par son $UID ).
⋅ Si dans ton nouveau système, tu crées de nouveaux utilisateurs qui auront de nouvelles données ( en plus de celles déjà existantes dans DATA ) alors il faut pour ces nouveaux utilisateurs leur créer dans DATA leur dossier « principal » où ils rangeront leurs affaires.

→ une telle partition DATA c'est ni plus ni moins la même structure qu'un dossier /home mais sans les éléments cachés ( qui eux restent dans les $HOME de chaque OS dont ils dépendent ).

_____________________

Je n'impose pas une organisation multi-utilisateurs sans avoir demandé si ce cas pourrait se produire
Sauf que le cas se produit à partir du moment où tu es sous Linux : tout son fonctionnement s'organise autour d'utilisateurs et groupes multiples, quand bien même il n'y aurait qu'un seul utilisateur humain enregistré. Utiliser Linux comme s'il était mono-utilisateur n'a aucun sens et mènera à des incompréhensions voire erreurs ( dans la gestion des données, dans qui a droit de faire quoi et dans quel emplacement… ). C'est évidemment plus simple quand il n'y a qu'un seul utilisateur humain, mais qu'il y en ait un ou mille ne change rien aux règles fondamentales de base…

Les supports USB non sécurisés ne méritent pas qu'on parle de propriétaire
Un support matériel appartient à root, au système. Si c'est un support nomade, externe, amovible à l'attention de plusieurs autres utilisateurs, alors root accorde aux autres sur ce support le droit de lire~écrire~exécuter.
C'est le seul cas ( clé usb, dd externe… ) où un sudo chmod 777 est tolérable. Mais ce support a bien un utilisateur propriétaire légitime, c'est root.

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#51 Le 27/02/2022, à 00:50

Re : [RÉSOLU] Sauvegarde sûre avant ré-installation : PC très très lent

#52 Le 27/02/2022, à 01:32

Re : [RÉSOLU] Sauvegarde sûre avant ré-installation : PC très très lent

#53 Le 27/02/2022, à 12:08

Re : [RÉSOLU] Sauvegarde sûre avant ré-installation : PC très très lent

#54 Le 27/02/2022, à 14:39

Re : [RÉSOLU] Sauvegarde sûre avant ré-installation : PC très très lent

#55 Le 27/02/2022, à 19:26

Re : [RÉSOLU] Sauvegarde sûre avant ré-installation : PC très très lent

#56 Le 27/02/2022, à 21:15

Re : [RÉSOLU] Sauvegarde sûre avant ré-installation : PC très très lent

#57 Le 27/02/2022, à 21:31

Re : [RÉSOLU] Sauvegarde sûre avant ré-installation : PC très très lent

#58 Le 28/02/2022, à 14:46

Re : [RÉSOLU] Sauvegarde sûre avant ré-installation : PC très très lent

#59 Le 01/03/2022, à 15:03

Re : [RÉSOLU] Sauvegarde sûre avant ré-installation : PC très très lent

#60 Le 01/03/2022, à 15:24

Re : [RÉSOLU] Sauvegarde sûre avant ré-installation : PC très très lent

#61 Le 02/03/2022, à 17:09

Re : [RÉSOLU] Sauvegarde sûre avant ré-installation : PC très très lent

#62 Le 02/03/2022, à 17:18

Re : [RÉSOLU] Sauvegarde sûre avant ré-installation : PC très très lent

#63 Le 02/03/2022, à 20:17

Re : [RÉSOLU] Sauvegarde sûre avant ré-installation : PC très très lent

#64 Le 03/03/2022, à 02:40

Re : [RÉSOLU] Sauvegarde sûre avant ré-installation : PC très très lent

#65 Le 03/03/2022, à 03:09

Re : [RÉSOLU] Sauvegarde sûre avant ré-installation : PC très très lent

#66 Le 03/03/2022, à 11:37

Re : [RÉSOLU] Sauvegarde sûre avant ré-installation : PC très très lent

#67 Le 03/03/2022, à 12:25

Re : [RÉSOLU] Sauvegarde sûre avant ré-installation : PC très très lent

#68 Le 03/03/2022, à 22:59

Re : [RÉSOLU] Sauvegarde sûre avant ré-installation : PC très très lent

#69 Le 07/03/2022, à 15:44

Re : [RÉSOLU] Sauvegarde sûre avant ré-installation : PC très très lent

#70 Le 07/03/2022, à 18:11

Re : [RÉSOLU] Sauvegarde sûre avant ré-installation : PC très très lent

#71 Le 07/03/2022, à 18:50

Re : [RÉSOLU] Sauvegarde sûre avant ré-installation : PC très très lent

#72 Le 03/04/2022, à 03:31

Re : [RÉSOLU] Sauvegarde sûre avant ré-installation : PC très très lent

Pied de page des forums