Bienvenido a Riosecoweb Hosting

soporte@riosecoweb.com   –  Ayuda / Faq  –
Ticket de Soporte

Soporte de lunes a Viernes
10:00-18:00

Teléfono Comercial +34 983 449 146

Migración de ownCloud a Nextcloud: cuando 137.000 bloqueos se interponen en el camino

La migración de datos nunca es un proceso trivial, pero a veces la realidad supera las previsiones. Eso fue exactamente lo que nos ocurrió tras el traslado de una instalación de ownCloud a Nextcloud: miles de archivos, aparentemente en perfecto estado, se negaban a abrirse en OnlyOffice.

En su lugar, un mensaje que se nos quedó grabado:

LockedException
"/admin/files/SFTP/rutadelarchivo/archivo.docx" is locked
Track: 1218316 status 2 error

No había candados en la interfaz web, no había usuarios editando el documento… y, sin embargo, la puerta seguía cerrada.

La pista apareció al revisar la base de datos. Allí, como un archivo policial lleno de pruebas, se encontraba la tabla oc_file_locks:

  • 137.268 registros ocupando 27,2 MiB.
  • Motor InnoDB, colación utf8mb4_bin.
  • Y cada entrada, un bloqueo que Nextcloud interpretaba como vigente.

La explicación no tardó en aparecer. Durante la migración, Nextcloud bloquea todos los archivos para evitar modificaciones que pongan en riesgo la integridad. El problema surge cuando, por un motivo u otro, el proceso no libera esos bloqueos. El resultado: una base de datos saturada de “locks” que no deberían existir.

Primero se intentó lo más ortodoxo: el comando de desbloqueo masivo de Nextcloud:

php occ files:unlock --all
php occ maintenance:repair

Pero la marea de bloqueos seguía ahí, inmutable. La solución llegó con una medida más drástica —y quirúrgica—: vaciar por completo la tabla.

El comando de la victoria fue tan breve como contundente:

DELETE FROM oc_file_locks WHERE 1;

Tras ello, un rápido php occ maintenance:repair y la vuelta al modo operativo (php occ maintenance:mode --off). Los errores LockedException desaparecieron de inmediato.

Consejo: vaciar el log de errores antes de consultarlo pues genera tantos, que la máquina servidor puede entrar en carga y quedar casi inaccesible.

La experiencia dejó claro que:

  1. La migración bloquea de forma preventiva todos los archivos.
  2. Si la liberación de bloqueos falla, el sistema queda atrapado en un estado que afecta a editores online.
  3. Vaciar oc_file_locks —previo respaldo— es una solución eficaz cuando los métodos estándar no funcionan.

Como medida preventiva, los expertos recomiendan ejecutar:

php occ files:unlock --all
php occ maintenance:repair

justo después de cualquier migración; cosa que a veces no funciona. Y, para quienes quieran ir un paso más allá, configurar Redis como backend de locking, minimizando la dependencia de la base de datos para esta tarea.

En este caso, el problema terminó con un simple borrado de registros. Pero detrás de esa aparente sencillez había una historia de investigación, diagnóstico y una base de datos que hablaba… solo había que saber escucharla.