jueves, 28 de mayo de 2026

PIKA no podía hacer backups: disco USB exFAT mal montado en Fedora 44

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

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.

domingo, 24 de mayo de 2026

Google Drive con rclone al inicio del sistema en Fedora 44

Cómo montar Google Drive con rclone al inicio en Fedora 44: error user_allow_other

Si al intentar montar Google Drive con rclone al inicio del sistema en Fedora 44 usando un servicio systemd de usuario el servicio falla, es posible que el problema sea la opción --allow-other y la configuración de FUSE. En esta entrada explico qué lo causa y cómo resolverlo.

¿Qué es este error?

Configuras el servicio en ~/.config/systemd/user/rclone-gdrive.service con la opción --allow-other, lo habilitas y al revisar los logs con:

journalctl --user -u rclone-gdrive.service -f

Aparece el siguiente mensaje:

mount helper error: fusermount3: option allow_other only allowed
if 'user_allow_other' is set in /etc/fuse.conf

Fatal error: failed to mount FUSE fs: fusermount: exit status 1

La opción --allow-other le indica a FUSE que otros usuarios del sistema puedan acceder al punto de montaje. Sin embargo, por seguridad, FUSE exige que esta capacidad esté explícitamente habilitada en el archivo de configuración del sistema /etc/fuse.conf.

En Fedora 44 esa línea existe en el archivo pero viene comentada con un # y un espacio delante:

# user_allow_other

Un sed automático puede no funcionar si hay espacio entre el # y el texto, dejando la línea sin cambios.

La solución

Abre el archivo de configuración de FUSE con privilegios de administrador:

sudo nano /etc/fuse.conf

Busca la línea que contiene user_allow_other. Aparecerá comentada así:

# user_allow_other

Elimina el # y el espacio para que quede exactamente así:

user_allow_other

Guarda y cierra el archivo. En nano: Ctrl+O para guardar, Ctrl+X para salir.

Reinicia el servicio:

systemctl --user restart rclone-gdrive.service

Verifica que está funcionando:

systemctl --user status rclone-gdrive.service
ls ~/GoogleDrive

Deberías ver el estado active (running) y el contenido de tu Google Drive en el directorio ~/GoogleDrive.

Alternativa: prescindir de --allow-other

Si eres el único usuario del equipo y no necesitas que otros accedan al montaje, la solución más sencilla es eliminar la opción --allow-other del archivo del servicio, evitando tocar /etc/fuse.conf:

nano ~/.config/systemd/user/rclone-gdrive.service
# Elimina la línea --allow-other

systemctl --user daemon-reload
systemctl --user restart rclone-gdrive.service

Referencia: servicio systemd completo

Este es el archivo de servicio systemd de usuario recomendado para Fedora 44. Guárdalo en ~/.config/systemd/user/rclone-gdrive.service:

[Unit]
Description=rclone Google Drive mount
After=network-online.target
Wants=network-online.target

[Service]
Type=notify
ExecStart=/usr/bin/rclone mount gdrive: %h/GoogleDrive \
    --vfs-cache-mode full \
    --vfs-cache-max-age 168h \
    --cache-dir %h/.cache/rclone \
    --dir-cache-time 1h \
    --log-level INFO \
    --allow-other
ExecStop=/bin/fusermount -u %h/GoogleDrive
Restart=on-failure
RestartSec=5

[Install]
WantedBy=default.target

El especificador %h se expande automáticamente al directorio home del usuario, por lo que no es necesario escribir la ruta completa.

Habilitar el arranque automático en el boot

Para que el servicio arranque en el boot sin necesidad de iniciar sesión interactiva, habilita el lingering del usuario:

loginctl enable-linger $USER

Resumen de comandos

# Editar fuse.conf y descomentar user_allow_other
sudo nano /etc/fuse.conf

# Recargar y reiniciar el servicio
systemctl --user daemon-reload
systemctl --user restart rclone-gdrive.service

# Verificar estado
systemctl --user status rclone-gdrive.service

# Ver logs en tiempo real
journalctl --user -u rclone-gdrive.service -f

# Habilitar arranque automático sin login
loginctl enable-linger $USER

Cómo eliminar el error PXE-E05 en el arranque con una tarjeta Intel 82571EB

Cómo eliminar el error PXE-E05 en el arranque con una tarjeta Intel 82571EB

Si al encender el ordenador aparece el siguiente mensaje y el arranque tarda más de lo normal, este artículo explica cómo solucionarlo definitivamente.

Initializing Intel(R) Boot Agent GE v.1.2.36
PXE 2.1 Build 085 (WfM 2.0), RPL v1.28
PXE-E05: The LAN adapter's NVM configuration is corrupted
         or has not been initialized. The Boot Agent cannot continue.

¿Qué es este error?

Este mensaje lo genera el Intel Boot Agent, un firmware grabado en la ROM de la tarjeta de red que permite arrancar el equipo desde la red (PXE boot). Es especialmente común en tarjetas de gama profesional/servidor como la Intel 82571EB Gigabit, donde el PXE viene activado de fábrica.

El error PXE-E05 indica que la NVM (memoria no volátil) de la tarjeta está corrupta o sin inicializar. La red sigue funcionando con normalidad una vez cargado el sistema operativo, pero el proceso de arranque se alarga innecesariamente mientras el Boot Agent intenta iniciarse y falla.

Identificar la tarjeta y sus puertos

En Linux, podemos identificar el hardware con:

lspci | grep Ethernet

En nuestro caso la salida fue:

02:00.0 Ethernet controller: Intel Corporation 82571EB/82571GB Gigabit Ethernet Controller D0/D1 (copper applications) (rev 06)
02:00.1 Ethernet controller: Intel Corporation 82571EB/82571GB Gigabit Ethernet Controller D0/D1 (copper applications) (rev 06)

Para saber el driver en uso:

lspci -k -s 02:00.0

Salida esperada:

Kernel driver in use: e1000e
Kernel modules: e1000e

La solución: Intel BootUtil

Intel proporciona una utilidad llamada BootUtil que permite modificar la configuración del Boot Agent directamente en la NVM de la tarjeta, de forma permanente e independiente de la BIOS.

La herramienta se descarga desde la página oficial de Intel: Intel® Ethernet Connections Boot Utility, Preboot Images, and EFI Drivers . Para Linux hay que descargar el archivo Preboot.tar.gz.

Una vez descomprimido, el ejecutable para Linux de 64 bits es bootutil64e.

Primer intento: -BOOTENABLE=disable

El comando habitual para desactivar el PXE es:

sudo ./bootutil64e -NIC=2 -BOOTENABLE=disable

Pero en nuestro caso devolvió un error:

Found discrete ROM in the flash for NIC 2
The -BOOTENABLE command can only be used on flashed combo images
Bad parameter

El problema es que la tarjeta tiene una ROM discreta en lugar de una imagen combo, por lo que el parámetro -BOOTENABLE no es compatible. El listado de puertos mostraba la situación:

Port  Network Address    Location         Series   WOL  Flash Firmware          Version
====  =================  ===============  =======  ===  ======================  =======
   1  C860000A7864       00000:000:25.0   Gigabit  YES  FLASH Not Present
   2  001517851DD6       00000:002:00.0   Gigabit  YES  PXE                     1.2.36
   3  001517851DD7       00000:002:00.1   Gigabit  N/A  FLASH Disabled

El puerto 2 (NIC 2) tenía el Boot Agent PXE activo, mientras que el puerto 3 ya estaba desactivado.

Solución correcta: -FLASHDISABLE

El comando correcto para ROM discreta es -FLASHDISABLE:

sudo ./bootutil64e -NIC=2 -FLASHDISABLE

Salida:

Intel(R) Ethernet Flash Firmware Utility
BootUtil version 1.43.32.0
Copyright (C) 2003-2026 Intel Corporation
Disabling boot ROM on port 2...Success

Port  Network Address    Location         Series   WOL  Flash Firmware          Version
====  =================  ===============  =======  ===  ======================  =======
   1  C860000A7864       00000:000:25.0   Gigabit  YES  FLASH Not Present
   2  001517851DD6       00000:002:00.0   Gigabit  YES  FLASH Disabled
   3  001517851DD7       00000:002:00.1   Gigabit  N/A  FLASH Disabled

Ambos puertos con FLASH Disabled. El cambio es permanente: se graba en la NVM de la tarjeta y persiste aunque se cambie de equipo o de BIOS.

Resultado

Al reiniciar, el mensaje PXE-E05 desapareció por completo y el arranque se redujo notablemente al eliminarse la espera del Boot Agent. La tarjeta de red sigue funcionando con normalidad en el sistema operativo, ya que el driver e1000e es completamente independiente del firmware de arranque PXE.

Resumen de comandos

# Identificar la tarjeta
lspci | grep Ethernet
lspci -k -s 02:00.0

# Descargar BootUtil desde Intel y descomprimir
tar -xzf Preboot.tar.gz
cd APPS/BootUtil/Linux_x64/

# Listar puertos y estado
sudo ./bootutil64e

# Deshabilitar el Boot Agent en ROM discreta
sudo ./bootutil64e -NIC=2 -FLASHDISABLE