Accès en écriture perdu

Support Debian
#1

Bonsoir,
La semaine dernière, une amie est venue me voir pour faire une sauvegarde de son téléphone sur une carte mémoire. J’ai fait la manip depuis mon PC, j’ai branché le téléphone et la carte mémoire en USB. J’ai copié ces données sans problème.

Bizarrement, en mettant la carte dans son nouveau téléphone, tout le contenu que j’y ai copié n’apparais pas. En re-branchant la carte sur mon PC, idem. Tout ce que j’y avais mis et qui était pourtant bien visible n’y est plus. Il y a bien quelques dossiers et photos, mais à peine une dizaine (sur +3.000 photos).

En re-branchant la carte mémoire pour faire une nouvelle copie, il refuse que je copie quoique se soit sur la carte. Elle est en lecture seul o.O …

En lançant nautilus en root, il refuse toujours d’écrire sur la carte je suis obligé de la formater pour qu’elle soit à nouveau accessible en lecture et écriture. Je lui ai dit que sa carte avais peut être un soucis, mais avec la nouvelle carte, le problème est le même …

Pour le moment je lui ai mis ces données dans une clé USB (en attendant de trouver si le problème viens de mon PC ou de sont téléphone) et là il n’y a apparemment pas de problème. Par contre, hier en voulant modifier sur mon 2e disque dure qui sert de disque de stockage, je n’ai pas le droit d’écriture et c’est un peu gênant parce que je me voie mal formater ce disque dans l’immédiat parce qu’il faudrait que je fasse d’abord une copie de ce disque. Et surtout, ça ne m’aidera pas à comprendre pourquoi d’un coup, certain disque/carte mémoire deviennent inaccessibles en écriture, même en root.

J’ai regardé les permissions du disque, il indique que le propriétaire est root, mais quand j’essaye de changer ça en root, il m’indique que le système de fichier est en lecture seul.

J’utilisais ce disque depuis des mois sans problème, est-ce que quelqu’un a déjà eu ce problème ?

Je suis sous Debian 9. Au cas ou sa aurait une importance, j’étais sous Debian 8 et j’ai mis-à-jour vers Stretch 1-2 semaines avant qu’il soit officiellement stable.

#2

Les fichiers qui disparaissent lors du passage de Debian8 à Debian9, c’est la spécialité de Stretch. Tu n’es pas le premier (je témoigne) et je pense que tu ne seras pas le dernier.

#3

Les fichiers perdu sa n’a rien à voir avec ma migration, qui a eu lieu début Juin. C’est une tentative de partiellement raté de sauvegarde du contenu d’un téléphone. J’aurais peut-être pas du commencé par sa, mais c’est comme sa que je me suis rendu compte que j’avais un problème.

J’ai continué à chercher sur internet et il se pourrait que se soit le système de fichier qui soit endommagé (je ne l’avais pas précisé mais c’est du NTFS), mais ntfsfix me dit qu’il ne peut rien faire et que je dois utiliser chkdsk.

#4

Pour la sauvegarde partielle je me demande si tu n’as pas retirer la carte trop vite et que finalement tu n’as pas tout copier. Il est recommander de démonter proprement ce genre de périphérique, soit avec un «umount» soit avec l’icone idoine dans nautilus.
Pour ton soucis de lecture seule es-ce que c’est directement en lecture seul dès le démarrage de la machine ? Peut être un concentrateur USB un peu foireux … dans tous les cas une lecture de «dmesg» et autre fichier dans /var/log est utile.

#5

Hé, le troll, il se calme !
Je n’ai jamais entendu parler de ça et je ne vois pas pourquoi des fichiers disparaitraient. Après, que certains fichier soient devenu illisible ou inaccessibles suite à un truc grand changement de version suite à une mise à jour, je veux bien y croire. Mais ça peut arriver avec n’importe quelle mise à jour.

#6

je n’ai pas dit que Debian est en cause, je dis seulement que les mises en garde au moment du passage de Jessie à Stretch, sont faiblardes.

#7

J’y ai pensé, du coup lorsque j’ai réessayé j’ai bien attendu que le barre de progression soit complètement pleine, appuyé sur le bouton d’éjection et attendu la confirmation avant de retirer la carte. Mais une fois dans le téléphone, même problème.

Pour mon disque, oui il est monté en lecture seul dès le démarrage (il est branché en interne).

Le retour de dmesg : https://pastebin.com/ybEG9GsY

Quels fichiers log en particulier ?

#8

Ça commence par ça :

[    4.757107] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null)

Ensuite, nous avons une ligne plus loin qui nous dit :

[    7.764872] EXT4-fs (sda1): re-mounted. Opts: errors=remount-ro

Je ne vois pas de ligne autour qui justifie ça.
Après, tu as :

[28347.790485] FAT-fs (sde1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.

et

[29342.434825] FAT-fs (sdd1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.

puis

[31907.440868] FAT-fs (sdd1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
[31907.465490] FAT-fs (sdd2): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.

Tu as donc sda1 qui se monte et qui tombe en erreur, puis, tu as sde1, sdd1 et sdd2 qui doivent être vérifiés car des erreurs se sont produites lors du démontage.
Est-il possible d’avoir les retours des commandes suivantes :

cat /etc/fstab
blkid
fdisk -l
mount

Merci.

#9

Voila :slight_smile:
cat /etc/fstab :

# /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/sda1 during installation
UUID=094d1763-e567-4d70-8482-3879c4a35fe1 /               ext4    errors=remount-ro 0       1
# swap was on /dev/sda5 during installation
UUID=2855f1ce-c0f3-4cb7-95a4-de2064c7cbb6 none            swap    sw              0       0
# Disque secondaire
UUID=C05247F95247F2A8 /media/Sauvegardes auto nosuid,nodev,nofail,x-gvfs-show 0 0
UUID=9cd3cb0f-4efc-4f4b-b80e-af42877360dd /media/Multimedia auto nosuid,nodev,nofail,x-gvfs-show 0 0

blkid :

/dev/sdc: LABEL="Multimedia" UUID="9cd3cb0f-4efc-4f4b-b80e-af42877360dd" TYPE="ext4"
/dev/sda1: UUID="094d1763-e567-4d70-8482-3879c4a35fe1" TYPE="ext4" PARTUUID="f24464a9-01"
/dev/sda5: UUID="2855f1ce-c0f3-4cb7-95a4-de2064c7cbb6" TYPE="swap" PARTUUID="f24464a9-05"
/dev/sdb1: LABEL="Sauvegardes" UUID="C05247F95247F2A8" TYPE="ntfs" PARTUUID="7b13ece1-01"

fdisk -l :

Disque /dev/sdc : 3,7 TiB, 4000787030016 octets, 7814037168 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 4096 octets
taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets


Disque /dev/sda : 465,8 GiB, 500107862016 octets, 976773168 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 4096 octets
taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets
Type d'étiquette de disque : dos
Identifiant de disque : 0xf24464a9

Périphérique Amorçage     Début       Fin  Secteurs Taille Id Type
/dev/sda1    *             2048 959997951 959995904 457,8G 83 Linux
/dev/sda2             959999998 976771071  16771074     8G  5 Étendue
/dev/sda5             960000000 976771071  16771072     8G 82 partition d'échange Linux / Solaris

La partition 2 ne commence pas sur une frontière de cylindre physique.


Disque /dev/sdb : 1,8 TiB, 2000398934016 octets, 3907029168 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 4096 octets
taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets
Type d'étiquette de disque : dos
Identifiant de disque : 0x7b13ece1

Périphérique Amorçage Début        Fin   Secteurs Taille Id Type
/dev/sdb1    *         2048 3907028991 3907026944   1,8T  7 HPFS/NTFS/exFAT

mount :

sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs (rw,nosuid,relatime,size=2005764k,nr_inodes=501441,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=404816k,mode=755)
/dev/sda1 on / type ext4 (rw,relatime,errors=remount-ro,data=ordered)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio)
cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=34,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=12274)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
mqueue on /dev/mqueue type mqueue (rw,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime)
sunrpc on /run/rpc_pipefs type rpc_pipefs (rw,relatime)
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
/dev/sdc on /media/Multimedia type ext4 (rw,nosuid,nodev,relatime,data=ordered)
/dev/sdb1 on /media/Sauvegardes type fuseblk (ro,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other,blksize=4096)
tmpfs on /run/user/121 type tmpfs (rw,nosuid,nodev,relatime,size=404812k,mode=700,uid=121,gid=128)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=404812k,mode=700,uid=1000,gid=1000)
gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)[/details]
#10

Jusque quelques commentaires, je n’ai pas regardé les messages du noyau (flemme).

Non, tu interprètes mal cette ligne. C’est juste le remontage de la racine avec les options classiques spécifiées dans /etc/fstab lors de l’init. La première fois, la racine était montée par l’initramfs sans ces options.

Ou plus probablement elles n’ont pas été démontées du tout. C’est peut-être un problème de séquencement, le périphérique étant arrêté avant que le système de fichiers soit démonté ou les écritures en attentes soient appliquées.

#11

Ah oui, un système de fichier sur le disque entier directement, pourquoi pas…

En effet. Après, est-ce que ça peut être la partition en ntfs qui pose problème ?

#12

sda1 et sda5 ont la même PARTUUID : normal ?

#13

Non, tu as mal lu. Impossible avec une table de partition DOS/MBR qui n’a pas de PARTUUID propre ; les PARTUUID sont reconstitués par le noyau à partir de l’identifiant du disque et du numéro de la partition. Les numéros de partition étant différents, les PARTUUID le sont donc aussi forcément.

#14

En effet, je n’avais pas déroulé totalement.
Ce n’est quand même pas courant de voir les 10 premiers caractères d’une UUID, identiques.

#15

Dans le cas d’une table de partition DOS/MBR, c’est systématique. J’ai expliqué la raison juste au dessus : les 8 premiers caractères représentent l’identifiant du disque (visible avec fdisk -l) et sont donc communs aux PARTUUID de toutes ses partitions, qui ne sont pas de vrais UUID mais sont construits par le noyau.

#16

OK, il faut dire que je compare avec moi, qui suis sur table GPT, où c’est sous forme ‘8-4-4-4-12’.

#17

C’est un disque que j’ai acheté récemment pour y stocker tout ce qui est multimédia, du coup j’ai créer une partition avec GParted qui prend tout le disque.

Il ne faut pas faire comme sa ?

#18

Si, c’est ce qu’il aurait été préférable de faire. Mais ce n’est pas ce que tu as fait.
sdc n’a pas de table de partition, donc pas de partition.

#19

Ah … pourtant je crois me souvenir que c’est comme sa que j’avais procédé … Je recommencerais à l’occasion.

Edit : Je voulais lancer une copie du contenu de mon disque multimedia pour la reformater à mon réveille (je vais me coucher là), mais j’avais oublié que mon disque de sauvegarde n’est plus accessible en écriture …

Personne n’a une idée de la source du problème ?

#20

Non. Les logs du noyau ne mentionnent pas le montage de sdb1, mais c’est peut-être normal puisque les systèmes de fichiers NTFS sont gérés par ntfs-3g via FUSE, donc en userland. Par contre on voit dans la sortie de mount que sdb1 est monté en lecture seule (ro), alors que cette option n’est pas présente dans /etc/fstab. Je ne sais pas où se trouvent les logs de FUSE, peut-être dans /var/log/syslog. Tu pourrais essayer de démonter sdb1 et de la remonter à la main avec mount voir si la commande affiche des informations dans la console.

Note : même si un disque non partitionné n’est pas l’idéal, ce n’est pas la peine de t’embêter à le repartitionner et le reformater. Cela fonctionne très bien ainsi, c’est juste qu’il est plus facile d’identifier le contenu d’un disque quand il est partitionné.