Contenu | Rechercher | Menus

Annonce

Si vous avez des soucis pour rester connecté, déconnectez-vous puis reconnectez-vous depuis ce lien en cochant la case
Me connecter automatiquement lors de mes prochaines visites.

À propos de l'équipe du forum.

#1 Le 25/02/2023, à 10:57

xt43

Changement inopérant de propriétaire d'un dossier/partition NTFS

Je viens de Windows où j'avais depuis longtemps délaissé de placer mes fichiers perso à encombrer le disque système SSD. Ils étaient et sont sur des partitions d'un disque classique. Migré sous Ubuntu 22.04.1 LTS, Gnome 42.4 depuis octobre 2022, j'ai conservé cette pratique.
Le problème est que le propriétaire n'est pas "moi" mais root et toutes mes tentatives pour changer ça ont échouées.
Ce matin j'ai encore tenté en m'inspirant de [Résolu] Changement de propriétaire impossible de root à user. Mais diverses choses étant différentes, je n'ai pas abouti et ai même eu un problème de boot avorté vers 12h, maintenant rétabli.

moi@canard:~$ sudo mount -v -a
/                         : ignoré
/boot/efi                 : déjà monté
none                      : ignoré
/mnt/Data-Docs-E          : déjà monté
/mnt/Sauvegardes nv       : déjà monté
/mnt/usb-Generic_STORAGE_DEVICE-0:0 : ignoré
moi@canard:~$ ls -l /media
total 4
drwxr-x---+ 5 root root 4096 févr. 21 15:23
 

Copie de mon fstab

ls# /etc/fstab: static file system information.

# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sda3 during installation
UUID=274c84dd-502e-43b1-8c27-c822f8f5ef00 /               ext4    errors=remount-ro 0       1
# /boot/efi was on /dev/sda2 during installation
UUID=062E-472A  /boot/efi       vfat    umask=0077      0       1
/swapfile                                 none            swap    sw              0       0
LABEL=copy\040of\040N /mnt/copy\040of\040N auto nosuid,nodev,nofail,x-gvfs-show 0 0
LABEL=Data-Docs-E /mnt/Data-Docs-E auto defaults,x-gvfs-show 0 0
LABEL=Sauvegardes\040nv /mnt/Sauvegardes\040nv auto nosuid,nodev,nofail,x-gvfs-show 0 0
/dev/disk/by-id/usb-Generic_STORAGE_DEVICE-0:0 /mnt/usb-Generic_STORAGE_DEVICE-0:0 auto nosuid,nodev,nofail,noauto,x-gvfs-show 0 0

À noter que "mnt/copy of N" est ma propriété depuis mes tentatives de ce matin 10:44.
Mais "Sauvegardes nv" reste à root.
Et Data-Docs-E a été fugacement  propriété de "moi" (qui contient la majorité de mes documents, téléchargements, etc.), mais est, avec ses sous-répertoires, de nouveau à root.
Et donc ce qui suit ne change rien

moi@canard:~$ sudo chown -R -c moi: /mnt/Data-Docs-E
...........................         pleins de fichiers, trop pour la mémoire écran
                                ........................................
appartenance de '/mnt/Data-Docs-E/Documents Xavier/Manuels Guides Notices/Alarme PowerMaster 30G2/Content/Resources/Manuals/Norwegian/D-305359 KP-250 PG2 User_NO_00.pdf' modifiée de root:root en moi:moi
appartenance de '/mnt/Data-Docs-E/Documents Xavier/Manuels Guides Notices/Alarme PowerMaster 30G2/Content/Resources/Manuals/Norwegian/D-305480 MC-302V_PG2_NO_00.pdf' modifiée de root:root en moi:moi
appartenance de '/mnt/Data-Docs-E/Documen
                                                     .......................................
                                                          pleins de fichiers,  
                                                                       .....................................
appartenance de '/mnt/Data-Docs-E/System Volume Information/_restore{EAFF0CA2-78DF-4071-8F13-C08955D0AFCF}/RP9/RestorePointSize' modifiée de root:root en moi:moi
appartenance de '/mnt/Data-Docs-E/System Volume Information/_restore{EAFF0CA2-78DF-4071-8F13-C08955D0AFCF}/RP9' modifiée de root:root en moi:moi
appartenance de '/mnt/Data-Docs-E/System Volume Information/_restore{EAFF0CA2-78DF-4071-8F13-C08955D0AFCF}' modifiée de root:root en moi:moi
appartenance de '/mnt/Data-Docs-E/System Volume Information' modifiée de root:root en moi:moi
appartenance de '/mnt/Data-Docs-E' modifiée de root:root en moi:moi
moi@canard:~$ 

Donc si quelqu'un a une solution, suffisamment explicite pour le néophyte que je suis, il sera le bienvenu.

Dernière modification par Ayral (Le 25/02/2023, à 11:07)


Débutant sous Ubuntu 22.04.3 LTS, Gnome 42.9, fenêtrage Wayland, 8Go de mémoire.
Système sur un SSD réservé, documents et autres sur disque interne classique.
Était avant sous W8.2 dont le disque système (SSD) a crashé.

Hors ligne

#2 Le 25/02/2023, à 11:42

geole

Re : Changement inopérant de propriétaire d'un dossier/partition NTFS

Bonjour
La solution est simple. Il est impossible de changer le propriétaire puisque c'est une délégation  de service de montage NTFS.
En quoi cela te gène-t-il ?.


Les grilles de l'installateur https://doc.ubuntu-fr.org/tutoriel/inst … _subiquity
"gedit admin:///etc/fstab" est proscrit,  utilisez "pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY xdg-open /etc/fstab" Voir  https://doc.ubuntu-fr.org/gedit
Les partitions EXT4 des disques externes => https://forum.ubuntu-fr.org/viewtopic.p … #p22697248

Hors ligne

#3 Le 25/02/2023, à 11:47

malbo

Re : Changement inopérant de propriétaire d'un dossier/partition NTFS

Bonjour,
Je suppose que tu as Windows en dual-boot avec Ubuntu dans ton ordi. Si c'est le cas, il faut désactiver le démarrage rapide de Windows comme indiqué dans ce tuto : https://www.pcastuces.com/pratique/astuces/5344.htm
Motif : quand le démarrage rapide de Windows est activé, toutes les partitions NTFS de l'ordi sont placées par Windows dans le mode hibernation à l'arrêt de Windows, ce qui fait que Ubuntu les monte obligatoirement en lecture seule, quelque soient les changements sur le propriétaire que tu pourrais tenter.

Dernière modification par malbo (Le 25/02/2023, à 11:49)

Hors ligne

#4 Le 25/02/2023, à 12:19

xt43

Re : Changement inopérant de propriétaire d'un dossier/partition NTFS

Bonjour
Je n'ai absolument plus de Windows, ne serait-ce que parce que je n'ai jamais apprécié MickeySoft.
En quoi ça me gêne ? S'agissant de mes données, ça me semble logiquement évident d'en être propriétaire. Et

xt43 (moi-même) a écrit :

À noter que "mnt/copy of N" est ma propriété depuis mes tentatives de ce matin 10:44.

mais n'ai pas saisi comment c'est arrivé.
De plus, si je pouvais faire pointer /home/moi sur cette partition|dossier c'est ce que je préférerais car je ne mets rien dans "Dossier personnel".


Débutant sous Ubuntu 22.04.3 LTS, Gnome 42.9, fenêtrage Wayland, 8Go de mémoire.
Système sur un SSD réservé, documents et autres sur disque interne classique.
Était avant sous W8.2 dont le disque système (SSD) a crashé.

Hors ligne

#5 Le 25/02/2023, à 12:38

geole

Re : Changement inopérant de propriétaire d'un dossier/partition NTFS

Si tu n'as pas windows, il est important de ne plus avoir à gérer des partitions NTFS, il faut que tu reformates en EXT4 voir en EXFAT.
En effet la gestion des réparations NTFS sous ubuntu est imparfaite.

Pour les liens, cela ressemblerait à cette commande

ln -s '/mnt/Data-Docs-E/Documents Xavier' DocXav

Mais il existe une règle ( paragraphe 4.4)

Dernière modification par geole (Le 25/02/2023, à 12:41)


Les grilles de l'installateur https://doc.ubuntu-fr.org/tutoriel/inst … _subiquity
"gedit admin:///etc/fstab" est proscrit,  utilisez "pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY xdg-open /etc/fstab" Voir  https://doc.ubuntu-fr.org/gedit
Les partitions EXT4 des disques externes => https://forum.ubuntu-fr.org/viewtopic.p … #p22697248

Hors ligne

#6 Le 25/02/2023, à 13:51

Coeur Noir

Re : Changement inopérant de propriétaire d'un dossier/partition NTFS

Si tu es dans un contexte 100% Linux alors il vaut mieux utiliser des systèmes de fichiers « compatibles » droits et permissions Linux, car comme le précise Geole « la gestion des réparations NTFS sous ubuntu est imparfaite » par exemple : Linux ne sait pas défragmenter du NTFS. À long terme c'est donc un risque de blocage voire de perte de données.

Les attributs sous Linux ( utilisateur et groupe propriétaires, droits, dates… ) sont portés directement par les fichiers. Sous NTFS ces attributs sont gérés de façon adéquate pour Windows mais pas pour Linux.

Cependant le « pilote » Linux qui gère NTFS possède des options de montage qui permettent de « superposer » des propriétaires et droits aux données contenus par la partition ( entre autres options possibles : uid, gid, umask, fmask, dmask ).
J'écris « superposer » car ça n'agit pas sur les éléments eux-mêmes, ça n'est effectif que côté Linux lorsqu'on consulte les données à travers ce montage.

Tu pourrais donc ajouter au montage des partitions NTFS les options adéquates, probablement :

uid=1000,gid=100,umask=027
# umask à 007 ou 002 selon le contexte ( multi-utilisateurs / à qui on veut laisser accès en écriture ou en lecture seule ou pas du tout. )
# le gid peut très bien être root (0) ou autre, selon contexte. 100 c'est le groupe users dans lequel on peut mettre tous les utilisateurs « humains » d'un système ( facilite le partage de données entre les utilisateurs membres du groupe. )
# l'uid 1000 est une supposition : le premier utilisateur créé sur une Ubuntu prend cette uid ( et gid ), le prochain utilisateur créé prendra 1001, etc.

Les options passées au montage d'une partition NTFS s'appliquent à tout le contenu de la partition une fois consulté depuis Linux, elles ne modifient pas les éléments eux-mêmes dans la partition puisque c'est un système de fichiers qui ne gère pas ces attributs « linuxiens » nativement ( on parle d'émulation des droits et permissions dans ce cas. )

Attention, les options de montage disponibles dépendent de chaque pilote pour chaque système de fichiers : ce qui est bon pour NTFS ne le sera pas pour EXT× ou pour Fat ou pour BtrFS…

Si tu as su changer directement les propriétaires des éléments contenus dans Data-Docs-E alors on peut supposer que cette partition héberge un système de fichiers compatibles Linux ( ext4 ou autre. )
On aurait une vue plus informative sur les disques et partitions en présence avec cette commande :

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

Permettra de voir « qui » est en NTFS ou autre.

Car là le relativement urgent c'est : sauvegarder ailleurs les données actuellement stockées en NTFS, reformater tes espaces de stockage en quelque chose de gérable à long terme par Linux ( EXT4 par ex. ), y organiser les dossiers convenablement ( un par utilisateur potentiel + sa corbeille ) et enfin réimporter les données sauvegardées ( dans chaque dossier utilisateur potentiel. )

Doc's utiles ( en + de celle déjà évoquée ) :
⋅ fstab https://doc.ubuntu-fr.org/mount_fstab
⋅ comment organiser une partition de données utilisateur(s) sous Linux https://doc.ubuntu-fr.org/organiser_dat … %C5%93uvre
⋅ les systèmes de fichiers https://doc.ubuntu-fr.org/systeme_de_fichiers
⋅ droits https://doc.ubuntu-fr.org/droits et permissions https://doc.ubuntu-fr.org/permissions ainsi que droits spéciaux https://www.redhat.com/sysadmin/suid-sgid-sticky-bit

Dernière modification par Coeur Noir (Le 25/02/2023, à 14:07)


DébuterDocBien rédigerRetour commandeInsérer image | illustrations & captures d'écran <>

Hors ligne

#7 Le 25/02/2023, à 18:11

xt43

Re : Changement inopérant de propriétaire d'un dossier/partition NTFS

Merci
C'est mon ordi perso et j'y suis le seul utilisateur ce qui simplifiera un peu.
Ça fait un moment que je songe à quitter NTFS mais j'ai reculé jusqu'ici devant la nécessite de tout sauvegarder ailleurs avant formatage : ma partition la plus importante Data-Docs-E contient 11845 fichiers pour 48,2 Go sur 194,8 Go de capacité. Mais, bon, je vais m'y résoudre. Quel système de fichiers me conseillez-vous ?
Notez que c'est une autre partition mnt/copy of N dont j'avais réussi à changer le propriétaire mais il s'avère qu'elle était vide mais NTFS.
Je vais maintenant potasser les docs conseillées.
Quant à faire pointer /home/moi sur cette partition|dossier, je verrais ça dans un second temps surtout que j'ignore la notion de lien unix.


Débutant sous Ubuntu 22.04.3 LTS, Gnome 42.9, fenêtrage Wayland, 8Go de mémoire.
Système sur un SSD réservé, documents et autres sur disque interne classique.
Était avant sous W8.2 dont le disque système (SSD) a crashé.

Hors ligne

#8 Le 25/02/2023, à 22:13

geole

Re : Changement inopérant de propriétaire d'un dossier/partition NTFS

Donc il faudra sauver puis reformater en ext4 puis restorer.
48 go de données c'est moins d'une heure.

Les liens sont comme pour windows,
On croit  qu'on va à tel endroit et cet endroit dit que c'est ailleurs.
et ailleurs peut dire que c'est bien chez lui ou autre part...
etc,,,,, au bout de 128 expéditions dans l'au-delà, le logiciel fait L'āne et refuse d'aller regarder ailleurs.

Dernière modification par geole (Le 25/02/2023, à 22:14)


Les grilles de l'installateur https://doc.ubuntu-fr.org/tutoriel/inst … _subiquity
"gedit admin:///etc/fstab" est proscrit,  utilisez "pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY xdg-open /etc/fstab" Voir  https://doc.ubuntu-fr.org/gedit
Les partitions EXT4 des disques externes => https://forum.ubuntu-fr.org/viewtopic.p … #p22697248

Hors ligne

#9 Le 27/02/2023, à 04:58

Coeur Noir

Re : Changement inopérant de propriétaire d'un dossier/partition NTFS

Dans le genre « description qui fait peur et crée de la confusion » c'est plutôt réussi lol

Un lien ( symbolique ) est un fichier spécial qu'on place où on veut, ce fichier spécial a une cible ( un fichier, un dossier ), et ce fichier spécial se comporte comme sa cible.
Effacer un lien symbolique ne supprime pas sa cible.
Effacer ( ou déplacer ou renommer ) la cible d'un lien symbolique « casse » le lien mais ne le supprime pas ; le lien est restauré dès lors que la cible existe à nouveau.
On peut déplacer un lien, le renommer ( lui donner un nom différent de sa cible. )

Il y a 2 types de lien :
⋅ le symbolique ( celui qui pourrait t'intéresser ) ou logiciel ou software ( d'où parfois l’appellation soft link ) et qui correspond à la description ci-dessus ;
⋅ le matériel, physique ou hardware ( d'où l'appellation hard link ) qui a un fonctionnement plus « bas niveau » et circonscrit à un système de fichier : sa cible n'est pas un fichier ou un dossier ( logiciel, symbolique ) mais directement les 0 et les 1 ( inode, matériel ) qui constituent un élément dans le système de fichiers. Quand il n'y a plus aucun lien physique vers un inode, ses 0 et ses 1 peuvent être libérés.

Évidemment créer un lien qui cible un autre lien qui cible un autre lien… au bout d'un moment on s'y perdrait, voire ça boucle. Suffit de pas le faire, hein :
les liens on les utilise avec parcimonie et les « symboliques » sont faciles à repérer ( leur icône porte une flèche ou un maillon, en commande ils sont facilement reconnaissables aussi. )

Discussion qui aborde aussi le sujet des liens → https://forum.ubuntu-fr.org/viewtopic.p … #p22654290

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


DébuterDocBien rédigerRetour commandeInsérer image | illustrations & captures d'écran <>

Hors ligne

#10 Le 02/03/2023, à 18:02

xt43

Re : Changement inopérant de propriétaire d'un dossier/partition NTFS

Merci Coeur Noir de ton message du 27/02/2023, à 04:58. Mais je ne m'occuperai des liens symboliques que dans un deuxième temps.
Je me suis d'abord occupé de ce que tu préconisais dans celui du 25/02/2023, à 13:51 (seulement récemment car j'ai d'autres soucis et occupations) et j'ai lu, pas encore assimilé, les docs que tu m'y proposais.
Et hier, j'ai voulu mettre en pratique et reformater en ext4 une partition ntfs, mais, commme premier essai, une autre qui contient des sauvegardes diverses et donc moins critique pour moi que Data-Docs-E contenant 48,2 Go. J'en ai donc déplacé le contenu, une partie actuellement, là ou j'avais de la place : le SSD où il y a le système (que j'ai voulu d'abord partitionner mais ça m'a été refusé). Mais là, il y a eu un schmilblick : ça a mis 26 heures pour déplacer  187 Go ce qui me semble considérable en comparaison de ce que je faisais sous Windows entre disques classiques, d'autant que la destination était un SSD. Et tout était considérablement ralenti y compris les affichages Internet. Ceci te semble-t-il normal ? Le déplacement est-il suspendu quand l'ordi se met en veille ?
Il faut maintenant que je finisse de vider ma partition ntfs en y faisant un ménage drastique puis la formater en ext4.Je m'occuperai ensuite de la partition qui contient mes données agnostiques.

J'ai été particulièrement intéressé par "comment organiser une partition de données utilisateur(s) sous Linux https://doc.ubuntu-fr.org/organiser_dat … %C5%93uvre" dont la philosophie correspond aux méthodes d'organisation que je pratique depuis des décennies, et je m'étonne que ce ne soit pas, sous un Unix, une organisation proposée à l'installation ou, au minimum, plus simple à mettre en oeuvre car mélanger paramètres et données perso ce n'est logique que pour l'ingénieur système, pas pour l'utilisateur.


Débutant sous Ubuntu 22.04.3 LTS, Gnome 42.9, fenêtrage Wayland, 8Go de mémoire.
Système sur un SSD réservé, documents et autres sur disque interne classique.
Était avant sous W8.2 dont le disque système (SSD) a crashé.

Hors ligne

#11 Le 02/03/2023, à 18:31

geole

Re : Changement inopérant de propriétaire d'un dossier/partition NTFS

Bonjour
Je pense que tu as voulu partitionner ta partition contenant le logiciel alors que tu utilisais le logiciel. Sous windows, c'est possible. Mais pas sous UBUNTU. il ne sait pas modifier une partition en cours d'utilisation    Il aurait fallu que tu bootes avec le support d'installation pour le faire. https://doc.ubuntu-fr.org/gparted

A mon avis tu as  un sacré bug.   Ce déplacement de 187 go aura du durer environ  une demie-heure car   c'est la vitesse de lecture du disque dur qui aurait été le frein. Je ne sais pas si on pourra retrouver la cause mais tente ce retour.

journalctl --since  "2023-02-27 13:00" --until  "2023-03-02 18:00" --no-pager -p err

Tu pourras ajuster les jours et les heures pour  ne prendre que ces 27 heures

Lorsque l'ordinateur se met en veille ( pas l'écran graphique),   plus rien ne travaille.


Les grilles de l'installateur https://doc.ubuntu-fr.org/tutoriel/inst … _subiquity
"gedit admin:///etc/fstab" est proscrit,  utilisez "pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY xdg-open /etc/fstab" Voir  https://doc.ubuntu-fr.org/gedit
Les partitions EXT4 des disques externes => https://forum.ubuntu-fr.org/viewtopic.p … #p22697248

Hors ligne

#12 Le 02/03/2023, à 18:48

Coeur Noir

Re : Changement inopérant de propriétaire d'un dossier/partition NTFS

[edit] quand j'ai commencé à écrire ce message, Geole n'avait pas déjà répondu, c'est donc un peu redondant.

Tu as raison d'agir par « étape », c'est prudent.

Et non je ne dirais pas que c'est normal, mais tu n'es semble-t-il pas seul avec ce souci de lenteur → https://forum.ubuntu-fr.org/viewtopic.php?id=2078004 donc Geole saura peut-être aiguiller.

Le déplacement est-il suspendu quand l'ordi se met en veille ?
Non, il me semble que des transferts de données en cours empêchent la mise en veille automatique du système ( l'écran s'éteindra au bout d'un temps d'inactivité, mais pas le système dans ce cas. )
C'est réglable, pour t'en assurer tu peux complètement désactiver la mise en veille ( = extinction du ) système et ne garder que l'extinction écran :
param-energie.png param-verrouillage-ecran.png

Par contre si tu déclenches manuellement une mise en veille ( via une touche « sleep » sur le clavier par ex. ) alors là oui, ça coupe tout ( et pas dit que les transferts reprennent gentiment à la sortie de veille… )

As-tu agi par copier-coller ou par couper-coller ? La première façon est plus prudente, tu effaces alors les données initiales seulement quand tu as constaté qu'elles sont correctement copiées dans la destination.

Après, même si NTFS est géré par Linux, il n'y est pas aussi bien géré que dans son OS d'origine ( Microsoft n'en a jamais complètement publié les spécifications, son implémentation dans Linux relève de rétro-ingénierie. )
Mais 26 heures pour 187Go à la louche ça fait à peine du 2Mo/s c'est …curieux.

j'ai voulu d'abord partitionner mais ça m'a été refusé
Sans doute normal : on ne peut pas intervenir sur des partitions montées, en cours d'utilisation. Or si tu visais le disque qui contient le système, difficile de démonter le système en cours ;-)
Pour ça, il faut passer par une « live session », depuis une clé usb contenant un OS Linux ou des utilitaires de partitionnement.

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


DébuterDocBien rédigerRetour commandeInsérer image | illustrations & captures d'écran <>

Hors ligne

#13 Le 02/03/2023, à 19:09

xt43

Re : Changement inopérant de propriétaire d'un dossier/partition NTFS

Merci geole
Pour le partitionnement, j'étais effectivement habitué à ce que le partitionnement de C: soit enregistré et effectué au démarrage. J'ai noté pour une prochaine fois.

moi@canard:~$ journalctl --since  "2023-02-28 9:00" --until  "2023-03-01 14:00" --no-pager -p err
févr. 28 09:55:50 canard kernel: ata1.00: SRST failed (errno=-16)
févr. 28 10:07:36 canard sudo[36655]: pam_unix(sudo:auth): conversation failed
févr. 28 10:07:36 canard sudo[36655]: pam_unix(sudo:auth): auth could not identify password for [moi]
févr. 28 10:07:36 canard sudo[36655]:      moi : a password is required ; PWD=/home/moi ; USER=root ; COMMAND=/usr/bin/uptime
févr. 28 14:46:29 canard kernel: ata1.00: SRST failed (errno=-16)
févr. 28 14:46:30 canard systemd[1]: Failed to start Refresh fwupd metadata and update motd.
févr. 28 16:47:18 canard kernel: sd 4:0:0:0: [sdd] tag#0 access beyond end of device
févr. 28 16:47:18 canard kernel: I/O error, dev sdd, sector 8192 op 0x1:(WRITE) flags 0x800 phys_seg 1 prio class 0
févr. 28 16:47:18 canard kernel: Buffer I/O error on dev sdd1, logical block 0, lost sync page write
mars 01 09:48:27 canard kernel: ata1.00: SRST failed (errno=-16)
mars 01 09:48:28 canard systemd[1]: Failed to start Refresh fwupd metadata and update motd.
moi@canard:~$ 

Si tu peux en déduire quelque chose parfait, mais moi, je n'en comprend pas beaucoup, seulement que je me suis trompé pour le mot de passe du 1° sudo.

Il faudra donc que je désactive la mise en veille pour des copies et autres opérations longues.


Débutant sous Ubuntu 22.04.3 LTS, Gnome 42.9, fenêtrage Wayland, 8Go de mémoire.
Système sur un SSD réservé, documents et autres sur disque interne classique.
Était avant sous W8.2 dont le disque système (SSD) a crashé.

Hors ligne

#14 Le 02/03/2023, à 19:32

Coeur Noir

Re : Changement inopérant de propriétaire d'un dossier/partition NTFS

Il faudra donc que je désactive la mise en veille pour des copies et autres opérations longues.
Bah il me semble que c'est pas la peine - mais si tu veux être sûr qu'il n'y aura pas de mise en veille automatique après un certain délai d'inactivité, tu la désactives tongue
Attention, ça n'interdira pas la mise en veille manuelle via une touche ou un raccourci clavier…

févr. 28 16:47:18 canard kernel: I/O error, dev sdd, sector 8192 op 0x1:(WRITE) flags 0x800 phys_seg 1 prio class 0
févr. 28 16:47:18 canard kernel: Buffer I/O error on dev sdd1, logical block 0, lost sync page write

Les disque « source » de données est-il ce sdd et sa partition sdd1 ?

Ça mériterait peut-être l'ouverture d'un nouveau fil de discussion dédié ?

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


DébuterDocBien rédigerRetour commandeInsérer image | illustrations & captures d'écran <>

Hors ligne

#15 Le 03/03/2023, à 10:58

xt43

Re : Changement inopérant de propriétaire d'un dossier/partition NTFS

Coeur Noir a écrit :

Ça mériterait peut-être l'ouverture d'un nouveau fil de discussion dédié ?

Je suis entièrement d'accord. Mais, comment faire dans la pratique ? Car, pour une bonne compréhension des lecteurs, il faudrait y reproduire ou transférer les derniers échanges entre toi, geole et moi et le faire par citations me semble peu adéquat.


Débutant sous Ubuntu 22.04.3 LTS, Gnome 42.9, fenêtrage Wayland, 8Go de mémoire.
Système sur un SSD réservé, documents et autres sur disque interne classique.
Était avant sous W8.2 dont le disque système (SSD) a crashé.

Hors ligne

#16 Le 03/03/2023, à 19:12

geole

Re : Changement inopérant de propriétaire d'un dossier/partition NTFS

Bonsoir.
Le retour de la commande "journalctl" ne montre aucune anomalie expliquant cette lenteur.
Il y a une erreur signalée sur le disque SDD. => installe donc l'application smarmontools (https://doc.ubuntu-fr.org/smartmontools)  et poste dans cette discussion le retour de cette commande.

sudo smartctl -s on -a  /dev/sdd

Tu feras aussi la même chose avec ton SSD  ( sda? ) bien que c'est rare de détecter des anomalies


La discussion pointée par coeur noir n'a aucun rapport avec une lenteur d'écriture,
Je pense que cela écrivait sur le disque  tournant à 5400 TPM avec un débit normal ( 50 Mo/s ).  Comme j'avais perdu la main au clavier, je n'ai pas pu mettre des outils de suivi et la commande que j'utilisais ne le fournit pas à sa terminaison.

Dernière modification par geole (Le 03/03/2023, à 19:19)


Les grilles de l'installateur https://doc.ubuntu-fr.org/tutoriel/inst … _subiquity
"gedit admin:///etc/fstab" est proscrit,  utilisez "pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY xdg-open /etc/fstab" Voir  https://doc.ubuntu-fr.org/gedit
Les partitions EXT4 des disques externes => https://forum.ubuntu-fr.org/viewtopic.p … #p22697248

Hors ligne

#17 Le 04/03/2023, à 16:26

xt43

Re : Changement inopérant de propriétaire d'un dossier/partition NTFS

La copie était de sdc3 (/mnt/Sauvegardes nv) vers sda3 (le SSD)
Le disque sdd n'existe pas réellement voir :
sdd vu par Disques : 1677941697.png
Je n'ai pas de disque ou de clé USB actuellement branché.
Mais j'ai installé smarmontools et la commande donne

moi@canard:~$ sudo smartctl -s on -a  /dev/sdd
[sudo] Mot de passe de moi : 
smartctl 7.2 2020-12-30 r5155 [x86_64-linux-5.19.0-32-generic] (local build)
Copyright (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org

/dev/sdd: Unknown USB bridge [0x05e3:0x0723 (0x9451)]
Please specify device type with the -d option.

Use smartctl -h to get a usage summary

moi@canard:~$ 

et avec sda (bien que  la doc de smartmontools dise : il est inutile de tester un SSD car les secteurs testés sont virtuels. Cela ne ferait que l'user de façon prématurée ! )

moi@canard:~$ sudo smartctl -s on -a  /dev/sda

Sinon, je n'ai pas compris ce que tu voulais dire dans ta dernière phrase " Comme j'avais perdu la main au clavier, je n'ai pas pu mettre des outils de suivi et la commande que j'utilisais ne le fournit pas à sa terminaison."
[sudo] Mot de passe de moi : 
smartctl 7.2 2020-12-30 r5155 [x86_64-linux-5.19.0-32-generic] (local build)
Copyright (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Device Model:     ADATA SU630
Serial Number:    2M062L1J9J2U
LU WWN Device Id: 0 000000 000000000
Firmware Version: XD0R024G
User Capacity:    240057409536 bytes [240 GB]
Sector Size:      512 bytes logical/physical
Rotation Rate:    Solid State Device
Form Factor:      2.5 inches
TRIM Command:     Available, deterministic
Device is:        Not in smartctl database [for details use: -P showall]
ATA Version is:   ACS-3, ATA8-ACS T13/1699-D revision 6
SATA Version is:  SATA 3.0, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:    Sat Mar  4 15:59:20 2023 CET
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF ENABLE/DISABLE COMMANDS SECTION ===
SMART Enabled.

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status:  (0x00)	Offline data collection activity
					was never started.
					Auto Offline Data Collection: Disabled.
Self-test execution status:      (   0)	The previous self-test routine completed
					without error or no self-test has ever 
					been run.
Total time to complete Offline 
data collection: 		(    1) seconds.
Offline data collection
capabilities: 			 (0x59) SMART execute Offline immediate.
					No Auto Offline data collection support.
					Suspend Offline collection upon new
					command.
					Offline surface scan supported.
					Self-test supported.
					No Conveyance Self-test supported.
					Selective Self-test supported.
SMART capabilities:            (0x0002)	Does not save SMART data before
					entering power-saving mode.
					Supports SMART auto save timer.
Error logging capability:        (0x01)	Error logging supported.
					General Purpose Logging supported.
Short self-test routine 
recommended polling time: 	 (   1) minutes.
Extended self-test routine
recommended polling time: 	 (   2) minutes.

SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   100   100   050    Pre-fail  Always       -       0
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0
  9 Power_On_Hours          0x0032   100   100   000    Old_age   Always       -       1260
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       275
160 Unknown_Attribute       0x0032   100   100   050    Old_age   Always       -       0
161 Unknown_Attribute       0x0032   100   100   050    Old_age   Always       -       100
163 Unknown_Attribute       0x0032   100   100   000    Old_age   Always       -       18
164 Unknown_Attribute       0x0032   100   100   000    Old_age   Always       -       3970
165 Unknown_Attribute       0x0032   100   100   000    Old_age   Always       -       8
166 Unknown_Attribute       0x0032   100   100   000    Old_age   Always       -       2
167 Unknown_Attribute       0x0032   100   100   000    Old_age   Always       -       5
148 Unknown_Attribute       0x0032   100   100   000    Old_age   Always       -       11910
149 Unknown_Attribute       0x0032   100   100   000    Old_age   Always       -       26
150 Unknown_Attribute       0x0032   100   100   000    Old_age   Always       -       8
151 Unknown_Attribute       0x0032   100   100   000    Old_age   Always       -       15
159 Unknown_Attribute       0x0032   100   100   000    Old_age   Always       -       0
168 Unknown_Attribute       0x0032   100   100   000    Old_age   Always       -       26
169 Unknown_Attribute       0x0032   100   100   000    Old_age   Always       -       100
177 Wear_Leveling_Count     0x0032   100   100   000    Old_age   Always       -       0
181 Program_Fail_Cnt_Total  0x0032   100   100   000    Old_age   Always       -       0
182 Erase_Fail_Count_Total  0x0032   100   100   000    Old_age   Always       -       0
192 Power-Off_Retract_Count 0x0032   100   100   000    Old_age   Always       -       15
194 Temperature_Celsius     0x0032   100   100   000    Old_age   Always       -       10
195 Hardware_ECC_Recovered  0x0032   100   100   000    Old_age   Always       -       0
196 Reallocated_Event_Count 0x0032   100   100   000    Old_age   Always       -       0
199 UDMA_CRC_Error_Count    0x0032   100   100   000    Old_age   Always       -       0
232 Available_Reservd_Space 0x0032   100   100   000    Old_age   Always       -       100
241 Total_LBAs_Written      0x0032   100   100   000    Old_age   Always       -       28318
242 Total_LBAs_Read         0x0032   100   100   000    Old_age   Always       -       6202
245 Unknown_Attribute       0x0032   100   100   000    Old_age   Always       -       41316

SMART Error Log Version: 1
No Errors Logged

SMART Self-test log structure revision number 1
No self-tests have been logged.  [To run self-tests, use: smartctl -t]

SMART Selective self-test log data structure revision number 0
Note: revision number not 1 implies that no selective self-test has ever been run
 SPAN  MIN_LBA  MAX_LBA  CURRENT_TEST_STATUS
    1        0        0  Not_testing
    2        0        0  Not_testing
    3        0        0  Not_testing
    4        0        0  Not_testing
    5        0        0  Not_testing
Selective self-test flags (0x0):
  After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.

moi@canard:~$ 

dont la compréhension dépasse largement mes capacités.

et pour vérifier les partitions montées

moi@canard:~$ sudo mount -v -a -l
/                         : ignoré
/boot/efi                 : déjà monté
none                      : ignoré
/mnt/copy of N            : déjà monté
/mnt/Data-Docs-E          : déjà monté
/mnt/Sauvegardes nv       : déjà monté
/mnt/usb-Generic_STORAGE_DEVICE-0:0 : ignoré
mount: /mnt/07A94E8E0560230A: le point de montage n'existe pas.
moi@canard:~$ 

Débutant sous Ubuntu 22.04.3 LTS, Gnome 42.9, fenêtrage Wayland, 8Go de mémoire.
Système sur un SSD réservé, documents et autres sur disque interne classique.
Était avant sous W8.2 dont le disque système (SSD) a crashé.

Hors ligne

#18 Le 04/03/2023, à 18:00

geole

Re : Changement inopérant de propriétaire d'un dossier/partition NTFS

Bonjour.
Comme prévu , rien de particulier signalé sur l'état du SSD. Ne confonds pas  demander l'état du SSD avec Tester le SSD.

Oublions le problème du SDD.

Pour la lenteur de copie. je ne sais quoi dire.

Il faudra que tu passes à la suite. Si je ne me trompe pas, c'est le formatage en EXT4.


Les grilles de l'installateur https://doc.ubuntu-fr.org/tutoriel/inst … _subiquity
"gedit admin:///etc/fstab" est proscrit,  utilisez "pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY xdg-open /etc/fstab" Voir  https://doc.ubuntu-fr.org/gedit
Les partitions EXT4 des disques externes => https://forum.ubuntu-fr.org/viewtopic.p … #p22697248

Hors ligne

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

xt43

Re : Changement inopérant de propriétaire d'un dossier/partition NTFS

Bien.
J'ai formaté la partition en ext4 et, d'ailleurs, ai été très surpris de l'immédiateté d'exécution.
Passé un peu de temps à renommer partition et dossier hébergeur en remplaçant les blancs par des underscore.
J'ai ensuite fait un sudo chown -R moi: /mnt/Sauvegardes_nv
Puis rapatrié mes fichiers ce qui s'est fait assez rapidement. Par précaution je l'ai fait dossier principal / dossier principal.

Je vais donc maintenant de m'occuper de la partition qui contient mes documents, images, etc.


Débutant sous Ubuntu 22.04.3 LTS, Gnome 42.9, fenêtrage Wayland, 8Go de mémoire.
Système sur un SSD réservé, documents et autres sur disque interne classique.
Était avant sous W8.2 dont le disque système (SSD) a crashé.

Hors ligne

#20 Le 05/03/2023, à 13:28

Coeur Noir

Re : Changement inopérant de propriétaire d'un dossier/partition NTFS

Seras-tu pour toujours et à jamais le seul utilisateur de ce système ?

https://forum.ubuntu-fr.org/viewtopic.p … #p22654238 [ le contexte est un peu différent mais le principe reste identique ]

Un point de montage, ça appartient à root:root et c'est accessible en lecture à tout le monde, pas la peine de changer cela.
Par contre dans la partition ext4 montée, tu crées un dossier que tu appropries à l'utilisateur souhaité, avec droits rwxr-x--- / 750 dans lequel seul cet utilisateur là pourra faire tout ce qu'il veut.

Si plusieurs utilisateurs → créer pour chacun un tel dossier → chacun ses affaires « chez lui ».

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


DébuterDocBien rédigerRetour commandeInsérer image | illustrations & captures d'écran <>

Hors ligne

#21 Le 06/03/2023, à 15:56

xt43

Re : Changement inopérant de propriétaire d'un dossier/partition NTFS

Catastrophe ! Le contenu de ma partition a disparu.
Ce que j'ai fait :
Hier PM, transfert des données de la partition  /mnt/Data-Docs-E (/dev/sda3) dans le dossier /z-svg-Data-Docs-E créé à cet effet dans la racine et donc dans la partition système /dev/sda3. Pour cela, le glisser-déplacer ne fonctionnait pas. Je pourrais dire ultérieurement ce que j'ai fait, mais l'urgence c'est d'essayer de récupérer mes données.
Ce matin, les transferts vers /z-svg-Data-Docs-E étant terminés, j'ai formaté avec Disques, en ext4 la partition /dev/sdb1 (Data-Docs-E)  et là encore j'ai été très surpris de la rapidité du formatage. puis j'ai commencé à y rapatrier les fichiers sauvegardés et comme le glisser-déplacer sous PCManFM, que je préfère de beaucoup à Nautilus n’était pas autorisé :

moi@canard:/z-svg-Data-Docs-E$ sudo mv Data_Xavier /mnt/Data-Docs-E
[sudo] Mot de passe de moi : 
moi@canard:/z-svg-Data-Docs-E$ sudo chown -R moi: .
moi@canard:/z-svg-Data-Docs-E$ sudo chown -R moi: /mnt/Data-Docs-E
moi@canard:/z-svg-Data-Docs-E$

Suite aux chown, j'ai pu rapatrier le reste par glisser-déplacer.
Puis ai procédé à quelques renommages de dossiers de tête pour remplacer les blancs par des underscore puis recréer les Marque-pages correspondants.
Le problème est que la partition est vide :

moi@canard:/z-svg-Data-Docs-E$ ls /mnt/Data-Docs-E
lost+found
moi@canard:/z-svg-Data-Docs-E$ 

J'ai fait une recherche de *Xavier* à partir de la racine et ça ne trouve rien.
À noter que sous Disques, /dev/sdb1 apparaissait "non monté" puis que je l'ai monté par Disques, mais

moi@canard:/z-svg-Data-Docs-E$ ls /mnt/Data-Docs-E
lost+found
moi@canard:/z-svg-Data-Docs-E$ 

Tout se passe comme si le formatage, bien qu'exécuté avant, avait été effectué après mes rapatriements.

Comment puis-je tenter de récupérer mes fichiers disparus ? car, faute d'une solution satisfaisante, le mec qui se considérais comme prudent et prévoyant, avait remis les sauvegardes à un jour ultérieur !!!


Débutant sous Ubuntu 22.04.3 LTS, Gnome 42.9, fenêtrage Wayland, 8Go de mémoire.
Système sur un SSD réservé, documents et autres sur disque interne classique.
Était avant sous W8.2 dont le disque système (SSD) a crashé.

Hors ligne

#22 Le 06/03/2023, à 16:22

MicP

Re : Changement inopérant de propriétaire d'un dossier/partition NTFS

Bonjour

Un conseil : N'utilise jamais la commande mv si tu veux transférer une série de fichiers ou/et répertoires d'un système de fichiers vers un autre système de fichiers :

Utilise plutôt la commande cp pour créer d'abord une copie dans la cible où tu veux déplacer tous les fichiers que tu voudrais déplacer,
ensuite vérifie que la copie a été bien faîte jusqu'au bout et qu'il n'y a pas d'erreur (en comparant le contenu de quelques fichiers)
et seulement après ça, tu pourras supprimer les fichiers source de la copie.

En résumé garde toujours les fichiers originaux à leur place tant que tu n'es pas sûr que leur copie a bien été créée et s'est bien terminée.

=======
Par contre, si tu veux déplacer des fichiers ou/et répertoires d'un répertoire vers un autre répertoire dans le même système de fichiers,
la commande mv ira très bien, et en plus, ce déplacement sera très très vite fait.

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

Hors ligne

#23 Le 06/03/2023, à 16:42

xt43

Re : Changement inopérant de propriétaire d'un dossier/partition NTFS

@MicP Merci du conseil qui me semble précieux. Mais, en l’occurrence, j'ai utilisé des glisser-déplacer comme je faisais sous Windows, sauf le 1° : Data_Xavier, qui ne me manquerais pas trop.
J'en reviens donc à "Comment puis-je tenter de récupérer mes fichiers disparus ?"


Débutant sous Ubuntu 22.04.3 LTS, Gnome 42.9, fenêtrage Wayland, 8Go de mémoire.
Système sur un SSD réservé, documents et autres sur disque interne classique.
Était avant sous W8.2 dont le disque système (SSD) a crashé.

Hors ligne

#24 Le 06/03/2023, à 16:52

geole

Re : Changement inopérant de propriétaire d'un dossier/partition NTFS

Bonjour
En lecture rapide, je pense que tu as fait un mv dans un point de montage  sans partition de montée sur ce point de montage.
Combien de temps a duré ta commande mv ?
donne ce retour pour identifier tout ce qui est monté

Ph=$LINES;Pw=$COLUMNS;printf "\033[8;${Ph};300t\n";sleep .1 && lsblk -fe7 -o+size;printf "\033[8;${Ph};${Pw}t\n"

Puis démonte toutes les partitions    qui sont montées sur /media et /mnt
Puis donne le retour de

ls -Rals /media
ls -Rals /mnt

Tu auras peut-être la chance d y trouver tes fichiers. Sinon, cela va se compliquer.

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


Les grilles de l'installateur https://doc.ubuntu-fr.org/tutoriel/inst … _subiquity
"gedit admin:///etc/fstab" est proscrit,  utilisez "pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY xdg-open /etc/fstab" Voir  https://doc.ubuntu-fr.org/gedit
Les partitions EXT4 des disques externes => https://forum.ubuntu-fr.org/viewtopic.p … #p22697248

Hors ligne

#25 Le 06/03/2023, à 17:54

MicP

Re : Changement inopérant de propriétaire d'un dossier/partition NTFS

Dans son message #23, xt43 a écrit :

…j'ai utilisé des glisser-déplacer …

L'interface graphique est bien faite :

En faisant un Glissé-déposer, alors …
- si la source et la cible sont bien deux systèmes de fichiers différents, alors elle fera une copie (<=> cp) des fichiers sans effacer l'original
- s'il s'agit du même système de fichiers, alors les fichiers seront effectivement déplacés (<=> mv) et ils ne seront donc plus présents là où ils étaient.

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

Hors ligne