Erreur Entrée/Sortie. Impossible afficher contenu d'un dossier. Fichiers .lock

[Joan]

Dernier message de la page précédente :

Scrat a écrit :

Il faut procéder pas à pas, sinon on n'en sortira pas. Donne seulement le retour de cette commande pour voir la racine du disque :

Code : Tout sélectionner

ls -la /media/yves/GIGA_TOSHIBA_E/

Ensuite on verra ce qu'il y a lieu de regarder.

Bonjour Scrat,

Retour ls -la /media/yves/GIGA_TOSHIBA_E/ :

La liste des Dossiers et Fichiers c'est 10 pages !!!… Soit environ 350 éléments !...
Je n'y voit rien à priori de problématique. Ce sont principalement des Fichiers .odt, .pdf, .png.
Cependant : 5 Fichiers .lockxxxxx.odt# que je cherche à virer mais qui ne posent pas de problèmes (entrée/sortie). 1 Fichier Thumbs.db ? 1 Fichier .Trash-1000 ?

Voici un extrait début et fin :

Code : Tout sélectionner

yves@yves-H81M-HD3 ~ $ ls -la /media/yves/GIGA_TOSHIBA_E/
total 582346
drwxrwxrwx  1 yves yves    102400 janv. 17 22:01 .
drwxr-x---+ 4 root root      4096 janv. 18 15:08 ..
-rwxrwxrwx  1 yves yves     25275 mai   27  2017 0000_RV_.odt
drwxrwxrwx  1 yves yves      4096 sept. 10 18:51 000_PERMANENTS
[...]
drwxrwxrwx  1 yves yves      4096 juil.  7  2018 0_A_SAUXXX_BO
-rwxrwxrwx  1 yves yves   1854192 janv. 25  2018 14-18_Charxxx_Rxxx_Pxxx.pdf
-rwxrwxrwx  1 yves yves    214841 juil.  9  2017 Caxxx du xxxx.png
-rwxrwxrwx  1 yves yves 442128982 févr. 28  2018 wetransfer-feac54.tar.gz
[…]
yves@yves-H81M-HD3 ~ $ 

Mais je n'y voit pas mes fichiers cachés comme celui qui pose problème : .~lock.Onxxx_xxx.odt# 

Joan

[cyrille]

Bon le problème est sur le disque


As tu essayé ntfsfix ?
https://doc.ubuntu-fr.org/ntfsfix

Code : Tout sélectionner

sudo ntfsfix /dev/sdb1 

Point de montage à adpater à ta config
Si tu premier message est tjs d'actualité, chez toi, cela devrait être : /dev/sdf1 mais à vérifier)

Ensuite reste à tester le disque avec smartmontools
https://cbiot.fr/dokuwiki/doku.php?id=f ... rtmontools

[Joan]

Cyrille a écrit :

Tu "kill" le processs […] Autant de fois que de pid […] sinon tu "kill" l'application.

Bonjour Cyrille,

Voici ce que me donne : ps aux | grep soffice

Code : Tout sélectionner

yves@yves-H81M-HD3 ~ $ ps aux | grep soffice
yves      4329  1.7  4.1 2001816 335448 ?      Sl   janv.18  22:33 /usr/lib/libreoffice/program/soffice.bin --writer file:///home/yves/0AA_ACAA_DOCUMENTS/0_1_LINUX_INFORMATIQUE/PB%20ORDI_TRAITEMENT%20PB/PB%20ENTRE-SORTIE_Janvier%202020/Solution%203.odt --splash-pipe=5
yves     25422  0.0  0.0  14264  1012 pts/0    S+   13:07   0:00 grep --color=auto soffice
yves@yves-H81M-HD3 ~ $ 

Donc c'est "kill 4329"
ou "killal soffice.bin" (Est-ce le bon libellé?)

Mais j'ai quelques appréhensions concernant « l'exécution » du Pid. Très probablement non-fondées. Même si j'ai fait des sauvegardes elles ne sont pas toutes très à jour. Ce que du reste je vais m'employer à faire. Avant d'aller plus loin j'aimerais mieux comprendre ce que je fais avec cette commande « tueuse ». Je ne voudrait pas effacer mes Dossiers et Fichiers très nombreux. Plusieurs années de travail...

Est-ce que "Kill 4329" va supprimer le fichier posant problème ? : /.~lock.Onxxx_xxx.odt# ?
J'ai bien compris que la commande ps permet d'afficher les processus actifs. Mais pourquoi faudrait-t-il les supprimer ? En quoi gênent-ils ? Et pourquoi supprimer "soffice.bin" ? En quoi ce fichier pose un problème d'entrée/sortie ?

Pour moi la cible à exécuter c'est ce Fichier caché : .~lock.Onxxx_xxx.odt# 

Confirme moi que je peux faire cette ces deux commandes sans crainte pour mes Dossiers et Fichiers. Merci de ton attention.

Par ailleurs je vais aussi prendre le temps de regarder ton message suivant de 17:28 et celui de ce jour à 12:58 dans lequel tu as identifié le problème : « le problème est sur le disque ». D'ores et déjà je t'indique que je n'ai jamais fait « ntfsfix ».

Je vais prendre le temps de décanter toutes ces précieuses indications en faisant attention… Je vois que ce problème emmène loin !…

Une question bête : Pourquoi je ne peux pas exécuter /.~lock.Onxxx_xxx.odt# directement ou le fichier Onxxx_xxx.odt ? Je redoute en plus à présent que ce genre de situation se reproduise sur un autre Fichier.

Merci de ta compréhension devant mes lacunes et de ton suivi,

Joan

[cyrille]

Laisse tomber ces histoires de PID et processus (le kill tue un processus qui pourrait utiliser une ressource et qui apparaitra par conséquent comme BUSY)
Regarde ma dernière suggestion par corriger directement ton disque.

[Joan]

Bien pris en compte

Joan

[Joan]

Laisse tomber ces histoires de PID et processus (le kill tue un processus qui pourrait utiliser une ressource et qui apparaitra par conséquent comme BUSY)
Regarde ma dernière suggestion par corriger directement ton disque.

Bien pris en compte,

Joan

[Joan]

Cyrille à écrit:

Bon le problème est sur le disque

As tu essayé ntfsfix ?
https://doc.ubuntu-fr.org/ntfsfix

Code : Tout sélectionner
sudo ntfsfix /dev/sdb1

Point de montage à adpater à ta config
Si tu premier message est tjs d'actualité, chez toi, cela devrait être : /dev/sdf1 mais à vérifier)

Ensuite reste à tester le disque avec smartmontools
https://cbiot.fr/dokuwiki/doku.php?id=f ... rtmontools

Il s'agit bien de /dev/sdf1 pour GIGA TOSHIBA_E

Avec blkid j'ai :

Code : Tout sélectionner

yves@yves-H81M-HD3 ~ $ blkid
[...]
/dev/sdf1: LABEL="GIGA_TOSHIBA_E" UUID="686415F26415C42A" TYPE="ntfs" PARTUUID="d0a056ec-01" = DD Externe

Mais avant de faire : sudo ntfsfix /dev/sdf1 ne faut-il pas que je démonte le système à vérifier, soit GIGA_TXXX ?

Ce que me confirme le retour :

Code : Tout sélectionner

yves@yves-H81M-HD3 ~ $ sudo ntfsfix /dev/sdf1
[sudo] Mot de passe de yves : 
Refusing to operate on read-write mounted device /dev/sdf1.
yves@yves-H81M-HD3 ~ $

« Refus de fonctionner sur un périphérique monté en lecture-écriture »

Donc pour démonter GIGAXXX je dois faire :

- sudo umount /dev/sdf1

Est-ce bien cela ?

Ou bien :

- sudo umont /media/yves/GIGA_TOSHIBA_E ?

Si je comprends bien cette opération va débrancher mon périphérique de l'OS - comme quand on retire une clef - ce qui permettra de le tester avec Smartmontools...

Je ne perdrai pas mes Dossiers/Fichiers GIGAxxx ?

Si il y a un risque je préfère prendre le temps de tout sauvegarder sur un autre disque dur externe. Ce sera un peu long mais ce sera fait. Ensuite je pourrai reprendre les opérations.
Je ne peux pas me permettre de perdre ces éléments.

Par la suite il faudra que j'installe smartmontools pour avoir des informations sur l'état de GIGAXXX

# apt-get install smartmontools

Merci Cyrille de tes réponses. Pour l'instant je sauvegarde.

Joan

[Joan]

Cyrille a écrit le 19 janvier :

As tu essayé ntfsfix ?
[…] Si tu premier message est tjs d'actualité, chez toi, cela devrait être : /dev/sdf1 mais à vérifier)

Bonjour Cyrille,

J'ai terminé mes sauvegardes. C'était important à faire en cas de « crash ».

1
Remarque de fond :

Avant de voir ce que donne "sudo ntfsfix" puis de tester le disque sur smartmontools pour réparer je fais une observation sur ce qui est sans aucun doute une anomalie de mon ordinateur depuis que je l'ai acquis il y a environ cinq ans.

DATA le disque dur interne a tendance à se déconnecter du volet gauche sans raison apparente. Parfois au bout d'un moment il revient. Parfois il me suffit d'éteindre et de redémarrer pour qu'il réapparaisse. C'est un problème récurrent. Problème de montage ? La raison m'échappe. Je note cependant – mais cela n'a peut-être rien à voir – que le "montage" de ce périphérique se lance en premier (Gparted) avant /boot/efi et / (et swap) qui sont en /dev/sdb.

Je me suis demandé si c'était bien conventionnel et si cela n'expliquerai pas quelques problèmes. Ne faudrait-il pas inverser les ordres et avoir d'abord en sda (et non pas en sdb), le système :

Code : Tout sélectionner

/dev/sdb1: UUID="3462-DE7E" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="123faee0-8862-43ba-875f-6bb903a42f39"
/dev/sdb2: UUID="105a618d-3db7-4847-bc94-51841a1c5d32" TYPE="ext4" PARTUUID="dd5fb420-28b2-414e-8511-cd68e601e029"
/dev/sdb3: UUID="a3c05bca-ef8b-45cd-8490-5b1e55185f94" TYPE="swap" PARTUUID="e1869dac-f106-4c02-b9fd-132e3f4ebcfd"

2
J'ai vérifié le chemin d'accès de GIGA TOSHIBA puisque c'est sur ce disque externe que j'ai le problème sur un fichier noté .lock « impossible accès problème entrée/sortie » (Au cours de ma sauvegarde j'en ai trouvé d'autres).
J'ai regardé avec « blkid ». Un première fois son chemin d'accès était : /dev/sde1. Mais la veille j'avais /dev/sdi1. Et depuis peu j'ai /dev/sdh1 ?... (Cela est confirmé par Gparted ou avec Disques).

Se peut-il que les chemins d'accès se promènent au grès des « caprices » numériques ?
Dans ce cas comment puis-je être sûr de faire sudo ntfsfix « partition » correctement ?

Une fois avec « blkid » j'ai : (/dev/sde1) :

Code : Tout sélectionner

yves@yves-H81M-HD3 ~ $ blkid
/dev/sda1: LABEL="DATA" UUID="18F06850F0683662" TYPE="ntfs" PARTUUID="8145ffdc-01"
/dev/sdb1: UUID="3462-DE7E" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="123faee0-8862-43ba-875f-6bb903a42f39"
/dev/sdb2: UUID="105a618d-3db7-4847-bc94-51841a1c5d32" TYPE="ext4" PARTUUID="dd5fb420-28b2-414e-8511-cd68e601e029"
/dev/sdb3: UUID="a3c05bca-ef8b-45cd-8490-5b1e55185f94" TYPE="swap" PARTUUID="e1869dac-f106-4c02-b9fd-132e3f4ebcfd"
/dev/sdc1: LABEL="SP PHD U3" UUID="1712-3D23" TYPE="vfat" PARTUUID="c32204e1-01"
/dev/sdd1: LABEL="STORE N GO" UUID="006E-AE4A" TYPE="vfat" PARTUUID="006eae4a-01"
/dev/sde1: LABEL="GIGA_TOSHIBA_E" UUID="686415F26415C42A" TYPE="ntfs" PARTUUID="d0a056ec-01"
yves@yves-H81M-HD3 ~ $ 

Une autre fois : (/dev/sdh1)

Code : Tout sélectionner

yves@yves-H81M-HD3 ~ $ blkid
/dev/sda1: LABEL="DATA" UUID="18F06850F0683662" TYPE="ntfs" PARTUUID="8145ffdc-01"
/dev/sdb1: UUID="3462-DE7E" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="123faee0-8862-43ba-875f-6bb903a42f39"
/dev/sdb2: UUID="105a618d-3db7-4847-bc94-51841a1c5d32" TYPE="ext4" PARTUUID="dd5fb420-28b2-414e-8511-cd68e601e029"
/dev/sdb3: UUID="a3c05bca-ef8b-45cd-8490-5b1e55185f94" TYPE="swap" PARTUUID="e1869dac-f106-4c02-b9fd-132e3f4ebcfd"
/dev/sdg1: LABEL="SP PHD U3" UUID="1712-3D23" TYPE="vfat" PARTUUID="c32204e1-01"
/dev/sdh1: LABEL="GIGA_TOSHIBA_E" UUID="686415F26415C42A" TYPE="ntfs" PARTUUID="d0a056ec-01"
/dev/sdi1: LABEL="STORE N GO" UUID="006E-AE4A" TYPE="vfat" PARTUUID="006eae4a-01"
yves@yves-H81M-HD3 ~ $

Avec sudo parted -l :

Code : Tout sélectionner

yves@yves-H81M-HD3 ~ $ sudo parted -l
[sudo] Mot de passe de yves : 
Modèle: ATA ST2000DM001-1ER1 (scsi)
Disque /dev/sda : 2000GB
Taille des secteurs (logiques/physiques): 512B/4096B
Table de partitions : msdos
Disk Flags: 

Numéro  Début   Fin     Taille  Type     Système de fichiers  Fanions
 1      1049kB  2000GB  2000GB  primary  ntfs


Modèle: ATA Samsung SSD 850 (scsi)
Disque /dev/sdb : 500GB
Taille des secteurs (logiques/physiques): 512B/512B
Table de partitions : gpt
Disk Flags: 

Numéro  Début   Fin    Taille  Système de fichiers  Nom                   Fanions
 1      1049kB  538MB  537MB   fat32                EFI System Partition  démarrage, esp
 2      538MB   492GB  491GB   ext4
 3      492GB   500GB  8475MB  linux-swap(v1)


Modèle: Verbatim STORE N GO (scsi)
Disque /dev/sdi : 15,7GB
Taille des secteurs (logiques/physiques): 512B/512B
Table de partitions : msdos
Disk Flags: 

Numéro  Début   Fin     Taille  Type     Système de fichiers  Fanions
 1      32,8kB  15,7GB  15,7GB  primary  fat32                démarrage


Modèle: PHD 3.0 Silicon-Power (scsi)
Disque /dev/sdg : 2000GB
Taille des secteurs (logiques/physiques): 512B/4096B
Table de partitions : msdos
Disk Flags: 

Numéro  Début   Fin     Taille  Type     Système de fichiers  Fanions
 1      1049kB  2000GB  2000GB  primary  fat32                démarrage, lba


Modèle: ASMT 2115 (scsi)
Disque /dev/sdh : 1000GB
Taille des secteurs (logiques/physiques): 512B/512B
Table de partitions : msdos
Disk Flags: 

Numéro  Début   Fin     Taille  Type     Système de fichiers  Fanions
 1      1049kB  1000GB  1000GB  primary  ntfs                 démarrage


yves@yves-H81M-HD3 ~ $ 

Merci par avance de m'éclairer sur ce dysfonctionnement et sur ce que je devrais faire pour le résoudre.

Bien cordialement,

Joan

[cyrille]

ça dépend de l'ordre dans lesquels tu branches tes periphs USB
Exemple avec deux cles USB

Code : Tout sélectionner

root@Fenrir:~# blkid 
/dev/sda1: UUID="aafffff0-7879-43c0-9be9-17207dd50f81" TYPE="ext4" PARTUUID="c15a2b33-01"
/dev/sda5: UUID="28d3dece-650b-4f82-8098-f10e1c3f5a4e" TYPE="swap" PARTUUID="c15a2b33-05"
/dev/sda6: UUID="77d5e00f-6170-4059-98c2-aa8d3c092625" TYPE="ext4" PARTUUID="c15a2b33-06"
/dev/sdb1: SEC_TYPE="msdos" UUID="5A16-29D5" TYPE="vfat"
/dev/sdd: SEC_TYPE="msdos" UUID="D246-C75A" TYPE="vfat"
/dev/sdc1: LABEL_FATBOOT="FAT32" LABEL="UUI" UUID="5E34-E900" TYPE="vfat" PARTUUID="9adf4b9d-01"

Je les démonte, ejecte, les branches sur les mêmes prises mais dans un ordre différent

Code : Tout sélectionner

root@Fenrir:~# blkid 
/dev/sda1: UUID="aafffff0-7879-43c0-9be9-17207dd50f81" TYPE="ext4" PARTUUID="c15a2b33-01"
/dev/sda5: UUID="28d3dece-650b-4f82-8098-f10e1c3f5a4e" TYPE="swap" PARTUUID="c15a2b33-05"
/dev/sda6: UUID="77d5e00f-6170-4059-98c2-aa8d3c092625" TYPE="ext4" PARTUUID="c15a2b33-06"
/dev/sdb1: LABEL_FATBOOT="FAT32" LABEL="UUI" UUID="5E34-E900" TYPE="vfat" PARTUUID="9adf4b9d-01"
/dev/sdc: SEC_TYPE="msdos" UUID="D246-C75A" TYPE="vfat"
/dev/sdd1: SEC_TYPE="msdos" UUID="5A16-29D5" TYPE="vfat"

Tu remarques qu'un coup l'UUID="5A16-29D5", par exemple, est monté sur /dev/sdb1 et l'autre coup sur /dev/sdd1

On s'en moque un peu, les fstab actuels prennent en compte les UUID et non les points de montage...

[Joan]

Cyrille a écrit, le 19 janvier:
Ensuite reste à tester le disque avec smartmontools

Donc bien noté que ce qui compte et ne varie pas c'est l'UUID.

1
blkid

Code : Tout sélectionner

yves@yves-H81M-HD3 ~ $ blkid
/dev/sda1: LABEL="DATA" UUID="18F06850F0683662" TYPE="ntfs" PARTUUID="8145ffdc-01"

/dev/sdb1: UUID="3462-DE7E" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="123faee0-8862-43ba-875f-6bb903a42f39"
/dev/sdb2: UUID="105a618d-3db7-4847-bc94-51841a1c5d32" TYPE="ext4" PARTUUID="dd5fb420-28b2-414e-8511-cd68e601e029"
/dev/sdb3: UUID="a3c05bca-ef8b-45cd-8490-5b1e55185f94" TYPE="swap" PARTUUID="e1869dac-f106-4c02-b9fd-132e3f4ebcfd"

/dev/sdc1: LABEL="SP PHD U3" UUID="1712-3D23" TYPE="vfat" PARTUUID="c32204e1-01"

/dev/sdd1: LABEL="GIGA_TOSHIBA_E" UUID="686415F26415C42A" TYPE="ntfs" PARTUUID="d0a056ec-01"

/dev/sde1: LABEL="STORE N GO" UUID="006E-AE4A" TYPE="vfat" PARTUUID="006eae4a-01"

yves@yves-H81M-HD3 ~ $ 

Donc GIGA TOSHIBA est monté sur: /dev/sdd1
UUID="686415F26415C42A

2
sudo ntfsfix /dev/sdd1

Code : Tout sélectionner

yves@yves-H81M-HD3 ~ $ sudo ntfsfix /dev/sdd1
[sudo] Mot de passe de yves : 
Refusing to operate on read-write mounted device /dev/sdd1.
yves@yves-H81M-HD3 ~ $ 

Pourtant hier j'avais :

Code : Tout sélectionner

yves@yves-H81M-HD3 ~ $ sudo ntfsfix /dev/sdh1
[sudo] Mot de passe de yves : 
Mounting volume... OK
Processing of $MFT and $MFTMirr completed successfully.
Checking the alternate boot sector... OK
NTFS volume version is 3.1.
NTFS partition /dev/sdh1 was processed successfully.
yves@yves-H81M-HD3 ~ $ 

"Refus de fonctionner sur un périphérique monté en lecture/écriture"
Pourtant l'accès aux Dossier et Fichiers fonctionnent correctement.
Je peux y écrire.

Que dois-je comprendre ?
Puis-je passer sur Smartmontools ?

Merci par avance Cyrille de tes conseils,

Joan

[cyrille]

lance déjà

Code : Tout sélectionner

sudo ntfsfix /dev/XXXXX

ensuite on verra la santé du disque et les badblocks....