PIKA no podía hacer backups: cómo un disco USB exFAT mal montado lo rompía todo en Fedora 44

28 de mayo de 2025  ·  Linux · Fedora · PIKA Backup · systemd

fedora backup systemd exfat pika udev

Llevaba tiempo sin revisar los backups automáticos con PIKA Backup cuando noté que el scheduler no había escrito nada en el disco externo desde semanas. El disco aparecía montado, GNOME no se quejaba, y sin embargo PIKA fallaba en silencio. Este artículo documenta la causa raíz y los pasos necesarios para solucionarlo de forma permanente.

❌ Síntoma principal El scheduler de PIKA Backup lanzaba el job pero fallaba al intentar escribir en el disco USB. Sin errores visibles en la interfaz — simplemente no había backups nuevos.

1. El entorno

Disco externo de 1,5 TB (Seagate SpinPoint M9T) formateado en exFAT, conectado por USB. Fedora 44 con escritorio GNOME. PIKA Backup ejecutándose como usuario normal (usuario).

Al conectar el disco, journalctl confirmaba que el kernel lo detectaba sin ningún problema:

sudo journalctl -b | grep sdf

May 28 20:49:54 kernel: sd 10:0:0:0: [sdf] 2930277167 512-byte logical blocks: (1.50 TB/1.36 TiB)
May 28 20:49:54 kernel: sd 10:0:0:0: [sdf] Write Protect is off
May 28 20:49:54 kernel: sd 10:0:0:0: [sdf] Write cache: enabled, read cache: enabled
May 28 20:49:54 kernel:  sdf: sdf1
May 28 20:49:54 kernel: sd 10:0:0:0: [sdf] Attached SCSI disk
May 28 20:50:03 smartd[1825]: Device: /dev/sdf [SAT], ST1500LM006 HN-M151RAD
May 28 20:50:04 smartd[1825]: Device: /dev/sdf [SAT], is SMART capable. Adding to "monitor" list.

Y mount mostraba el disco montado en modo lectura-escritura:

mount | grep sdf

/dev/sdf1 on /run/media/usuario/BACKUP_USB type exfat
  (rw,nosuid,nodev,relatime,fmask=0022,dmask=0022,
   iocharset=utf8,errors=remount-ro,x-gvfs-show)

2. La causa raíz

Aunque el mount indicaba rw, el disco lo había montado udisks2 — el gestor de dispositivos de GNOME — sin especificar uid ni gid. El resultado: los directorios quedaban con propietario root y permisos 755 debido al dmask=0022. El usuario normal no tenía permiso de escritura aunque el flag rw estuviera presente.

Al intentar escribir manualmente se confirmaba el problema:

mount /dev/sdf1
mount: /run/media/usuario/BACKUP_USB: must be superuser to use mount.

PIKA Backup, corriendo como usuario, intentaba escribir en un directorio que no le pertenecía. Sin mensaje de error en la UI — silencio total.

⚠️ El flag rw no garantiza que puedas escribir En sistemas de ficheros como exFAT, los permisos de usuario se determinan por uid, gid, fmask y dmask en el momento del montaje. Si montas sin uid=TU_UID, el propietario efectivo es root.

3. Solución permanente: systemd mount + udev

La solución tiene dos partes: una unidad .mount de systemd que monta el disco con las opciones correctas de usuario, y una regla udev que impide que udisks2 se adelante cuando se conecta el dispositivo.

Paso 1 — Obtener el UUID del disco

sudo blkid /dev/sdf1
# /dev/sdf1: UUID="1A2B-3C4D" TYPE="exfat"

Paso 2 — Crear la unidad systemd .mount

El nombre del fichero debe coincidir exactamente con el punto de montaje, sustituyendo / por -:

sudo nano /etc/systemd/system/run-media-usuario-BACKUP_USB.mount

[Unit]
Description=BACKUP_USB exFAT
After=udisks2.service

[Mount]
What=UUID=1A2B-3C4D
Where=/run/media/usuario/BACKUP_USB
Type=exfat
Options=uid=1000,gid=1000,fmask=0133,dmask=0022,rw,noatime

[Install]
WantedBy=multi-user.target

Paso 3 — Crear la unidad .automount para hot-plug

Sin esta unidad, el disco solo se monta si está conectado en el arranque. Para que funcione al conectarlo en caliente:

sudo nano /etc/systemd/system/run-media-usuario-BACKUP_USB.automount

[Unit]
Description=Automount BACKUP_USB
After=udisks2.service

[Automount]
Where=/run/media/usuario/BACKUP_USB
TimeoutIdleSec=0

[Install]
WantedBy=multi-user.target

Paso 4 — Crear el punto de montaje y activar las unidades

sudo mkdir -p /run/media/usuario/BACKUP_USB
sudo systemctl daemon-reload
sudo systemctl enable --now run-media-usuario-BACKUP_USB.mount
sudo systemctl enable --now run-media-usuario-BACKUP_USB.automount

Paso 5 — Evitar que udisks2 se adelante

El automount fallará si udisks o GNOME montan el disco antes que systemd. Para impedirlo creamos una regla udev que le ordena a udisks ignorar este dispositivo concreto identificado por UUID:

sudo nano /etc/udev/rules.d/99-backup-usb-nomount.rules

ENV{ID_FS_UUID}=="1A2B-3C4D", ENV{UDISKS_IGNORE}="1"

sudo udevadm control --reload-rules
sudo udevadm trigger

---

4. Error intermedio durante la configuración

Al activar el automount con el disco ya montado por udisks, systemd devolvía este error:

run-media-usuario-BACKUP_USB.automount:
  Path /run/media/usuario/BACKUP_USB is already a mount point, refusing start.

La solución inmediata es desmontar primero lo que haya montado udisks y luego arrancar el automount:

sudo umount /dev/sdf1
sudo systemctl start run-media-usuario-BACKUP_USB.automount

Una vez activa la regla udev, esto ya no es necesario porque udisks ignora el dispositivo desde el primer momento.

5. Verificación

1. Desconecta y vuelve a conectar el disco.
2. Comprueba el estado: systemctl status run-media-usuario-BACKUP_USB.automount
3. Verifica propietario: ls -la /run/media/usuario/BACKUP_USB — debe aparecer tu usuario, no root.
4. Lanza un backup manual desde PIKA Backup y confirma que escribe sin errores.
5. Espera al siguiente ciclo del scheduler y verifica que el backup automático se ha completado.

✅ Resultado Con la regla udev activa, udisks ignora el disco al conectarlo. El automount de systemd toma el control y lo monta con uid=1000, dando al usuario pleno acceso de escritura. PIKA Backup vuelve a ejecutar sus backups automáticos correctamente.

---