Cómo recuperar el sistema de archivos de un pendrive

Valoración del Usuario:  / 4
MaloBueno 

Hoy conecté mi pendrive Kingston en mi CentOS 6.4 y cuando quise borrar un archivo que se encontraba en el mismo recibí un error indicando que no podía borrar el archivo debido a que se trataba de un sistema de archivos de sólo lectura:

# rm /media/KINGSTON/archivo.zip
rm: cannot remove `/media/KINGSTON/archivo.zip': Read-only file system

¿Por qué mi pendrive está montado cómo sólo lectura?

Este artículo explica por qué sucede esto y cómo repararlo.



Antes de comenzar a dispararle al problema ("troubleshooting" jeje) vamos a desmontar y desconectar físicamente el dispositivo. En mi caso se trata de un pendrive Kingston que el sistema operativo CentOS 6 ha montado en el subárbol "/media/KINGSTON" (para determinar en que directorio está montado el pendrive basta ejecutar mount sin parámetros):

# umount /media/KINGSTON

Luego de desmontar y desconectar el pendrive, abrimos el log de mensajes del kernel utilizando tail, para poder ver qué informa el kernel Linux cuando conectamos el dispositivo:

# tail -f /var/log/messages

Al conectar el dispositivo comienzan a aparecer los siguientes mensajes en la salida de tail:

Jun  7 10:07:18 hal9000 kernel: usb 2-1.5: new high speed USB device number 4 using ehci_hcd
Jun  7 10:07:18 hal9000 kernel: usb 2-1.5: New USB device found, idVendor=0930, idProduct=6544
Jun  7 10:07:18 hal9000 kernel: usb 2-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Jun  7 10:07:18 hal9000 kernel: usb 2-1.5: Product: DT 101 G2
Jun  7 10:07:18 hal9000 kernel: usb 2-1.5: Manufacturer: Kingston
Jun  7 10:07:18 hal9000 kernel: usb 2-1.5: SerialNumber: 0019E06B0851CCA197252FBB
Jun  7 10:07:18 hal9000 kernel: usb 2-1.5: configuration #1 chosen from 1 choice
Jun  7 10:07:18 hal9000 kernel: scsi7 : SCSI emulation for USB Mass Storage devices
Jun  7 10:07:19 hal9000 kernel: scsi 7:0:0:0: Direct-Access     Kingston DT 101 G2        1.00 PQ: 0 ANSI: 4
Jun  7 10:07:19 hal9000 kernel: sd 7:0:0:0: Attached scsi generic sg2 type 0
Jun  7 10:07:19 hal9000 kernel: sd 7:0:0:0: [sdb] 30297216 512-byte logical blocks: (15.5 GB/14.4 GiB)
Jun  7 10:07:19 hal9000 kernel: sd 7:0:0:0: [sdb] Write Protect is off
Jun  7 10:07:19 hal9000 kernel: sd 7:0:0:0: [sdb] Assuming drive cache: write through
Jun  7 10:07:19 hal9000 kernel: sd 7:0:0:0: [sdb] Assuming drive cache: write through
Jun  7 10:07:19 hal9000 kernel: sdb: sdb1
Jun  7 10:07:19 hal9000 kernel: sd 7:0:0:0: [sdb] Assuming drive cache: write through
Jun  7 10:07:19 hal9000 kernel: sd 7:0:0:0: [sdb] Attached SCSI removable disk
Jun  7 10:07:20 hal9000 kernel: FAT: Filesystem error (dev sdb1)
Jun  7 10:07:20 hal9000 kernel:    invalid access to FAT (entry 0x0a7ec26b)
Jun  7 10:07:20 hal9000 kernel:    File system has been set read-only
Jun  7 10:07:20 hal9000 kernel: FAT: Filesystem error (dev sdb1)
Jun  7 10:07:20 hal9000 kernel:    invalid access to FAT (entry 0x0a7ec26b)

El sistema reconoce el dispositivo y le asigna el nombre de dispositivo "sdb" correctamente, pero cuando intenta montar el sistema de archivos (el cual se encuentra en la partición "sdb1") encuentra un error y lo remonta read-only:

Jun  7 10:07:20 hal9000 kernel: FAT: Filesystem error (dev sdb1)
Jun  7 10:07:20 hal9000 kernel:    invalid access to FAT (entry 0x0a7ec26b)
Jun  7 10:07:20 hal9000 kernel:    File system has been set read-only

Claramente se trata de un sistema de archivos que ha sido corrompido, seguramente la última vez que fue desmontado (o desconectado "a lo bestia" sin desmontar previamente). En mi caso el culpable fue el gilipollas empleado de mi casa fotográfica de confianza (en una ocasión en la que llevé a imprimir unas fotografías).

Para reparar el sistema de archivos, primero vamos a determinar el nombre de la partición donde se encuentra alojado:

# mount | grep vfat
/dev/sdb1 on /media/KINGSTON type vfat (rw,nosuid,nodev,uhelper=udisks,uid=500,gid=500,shortname=mixed,dmask=0077,utf8=1,flush)

Tal como se observa en la salida del comando mount, el sistema de archivos del pendrive (montado en el subárbol "/media/KINGSTON") se encuentra en el dispositivo "/dev/sdb1".

Por lo tanto desmontamos el dispositivo /dev/sdb1:

# umount /dev/sdb1

IMPORTANTE!!! Es necesario asegurarse que el sistema de archivos esté desmontado antes de intentar repararlo.

Para verificar y reparar el filesystem utilizamos la herramienta fsck.msdos ya que se trata de un sistema de archivos VFAT. Si el sistema de archivos es NTFS se debe utilizar fsck.ntfs:

# fsck.msdos -awvV /dev/sdb1

La salida del comando puede ser una chorrera de mensajes como los siguientes, dependiendo de cuan dañado esté el sistema de archivos:

dosfsck 3.0.9 (31 Jan 2010)
dosfsck 3.0.9, 31 Jan 2010, FAT32, LFN
Checking we can access the last sector of the filesystem
There are differences between boot sector and its backup.
Differences: (offset:original/backup)
  65:01/00
  Not automatically fixing this.
Boot sector contents:
System ID "THREES  "
Media byte 0xf8 (hard disk)
       512 bytes per logical sector
      8192 bytes per cluster
        32 reserved sectors
First FAT starts at byte 16384 (sector 32)
         2 FATs, 32 bit entries
   7570432 bytes per FAT (= 14786 sectors)
Root directory start at cluster 2 (arbitrary size)
Data area starts at byte 15157248 (sector 29604)
   1891673 data clusters (15496585216 bytes)
63 sectors/track, 32 heads
        63 hidden sectors
  30296385 sectors total
Starting check/repair pass.
Cluster 1470591 out of range (228497476 > 1891674). Setting to EOF.
Cluster 1470593 out of range (15148248 > 1891674). Setting to EOF.
Cluster 1470595 out of range (33642170 > 1891674). Setting to EOF.
Cluster 1470597 out of range (50061838 > 1891674). Setting to EOF.
Cluster 1470599 out of range (5006860 > 1891674). Setting to EOF.
Cluster 1470601 out of range (5849983 > 1891674). Setting to EOF.
Cluster 1470603 out of range (213087397 > 1891674). Setting to EOF.
Cluster 1470605 out of range (112942055 > 1891674). Setting to EOF.
Cluster 1470607 out of range (183090718 > 1891674). Setting to EOF.
Cluster 1470609 out of range (34862787 > 1891674). Setting to EOF.
Cluster 1470611 out of range (133720333 > 1891674). Setting to EOF.
Cluster 1470613 out of range (50845958 > 1891674). Setting to EOF.
Cluster 1470615 out of range (90824247 > 1891674). Setting to EOF.
             

Al finalizar, la herramienta fsck.msdos ha reparado el sistema de archivos y es posible desconectar y reconectar el dispositivo para asegurarse de que sea montado read-write, como corresponde:

# tail -f /var/log/messages
Jun  7 10:23:36 hal9000 kernel: usb 2-1.5: new high speed USB device number 5 using ehci_hcd
Jun  7 10:23:36 hal9000 kernel: usb 2-1.5: New USB device found, idVendor=0930, idProduct=6544
Jun  7 10:23:36 hal9000 kernel: usb 2-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Jun  7 10:23:36 hal9000 kernel: usb 2-1.5: Product: DT 101 G2
Jun  7 10:23:36 hal9000 kernel: usb 2-1.5: Manufacturer: Kingston
Jun  7 10:23:36 hal9000 kernel: usb 2-1.5: SerialNumber: 0019E06B0851CCA197252FBB
Jun  7 10:23:36 hal9000 kernel: usb 2-1.5: configuration #1 chosen from 1 choice
Jun  7 10:23:36 hal9000 kernel: scsi8 : SCSI emulation for USB Mass Storage devices
Jun  7 10:23:37 hal9000 kernel: scsi 8:0:0:0: Direct-Access     Kingston DT 101 G2        1.00 PQ: 0 ANSI: 4
Jun  7 10:23:37 hal9000 kernel: sd 8:0:0:0: Attached scsi generic sg2 type 0
Jun  7 10:23:37 hal9000 kernel: sd 8:0:0:0: [sdb] 30297216 512-byte logical blocks: (15.5 GB/14.4 GiB)
Jun  7 10:23:37 hal9000 kernel: sd 8:0:0:0: [sdb] Write Protect is off
Jun  7 10:23:37 hal9000 kernel: sd 8:0:0:0: [sdb] Assuming drive cache: write through
Jun  7 10:23:37 hal9000 kernel: sd 8:0:0:0: [sdb] Assuming drive cache: write through
Jun  7 10:23:37 hal9000 kernel: sdb: sdb1
Jun  7 10:23:37 hal9000 kernel: sd 8:0:0:0: [sdb] Assuming drive cache: write through
Jun  7 10:23:37 hal9000 kernel: sd 8:0:0:0: [sdb] Attached SCSI removable disk

Cabe destacar que durante el proceso de recuperación no perdí ni se corrompió ningún archivo. Aunque no siempre puede resultar así, depende del daño que haya sufrido el dispositivo.

Esta vez no hay problemas y el sistema de archivos se monta de forma correcta. Ahora es posible borrar el archivo:

# rm /media/KINGSTON/archivo.zip
rm: remove regular empty file `/media/KINGSTON/archivo.zip'? y
# ll /media/KINGSTON/archivo.zip
ls: cannot access /media/KINGSTON/archivo.zip: No such file or directory

Exito!



Suscribirse

    Registrate para recibir las novedades y artículos por correo electrónico.

Linuxito en G+