Cómo actualizar Nextcloud a la versión 35 con Docker sin perder datos

Actualizar Nextcloud 34 a 35 en Docker consiste en copiar la base de datos y el volumen, cambiar la etiqueta de la imagen y dejar que el contenedor ejecute occ upgrade al arrancar. Lo probé el 28 de septiembre de 2026 con las imágenes oficiales nextcloud:34.0.4 y nextcloud:35.0.1, MariaDB 11.8 y Redis 8, en una máquina arm64. La instancia tenía usuarios, archivos compartidos, un calendario, un tablero de Deck y siete apps de la tienda. Esta guía recoge cada aviso que salió, qué significa y cómo volví a la 34 desde la copia. Tienes también la versión en inglés de esta guía.

Puntos clave

• Nextcloud 35 (Hub 26 Summer) salió el 15 de septiembre de 2026, y la 35.0.1 el 24 de septiembre; la imagen oficial trae PHP 8.5.11.
• La 35 deja de admitir PHP 8.2, MariaDB 10.6 y MySQL 8.0: el mínimo pasa a ser MariaDB 10.11 o MySQL 8.4.
• Solo se sube una versión mayor cada vez; la imagen se niega a arrancar si intentas saltarte una o volver atrás.
• El 28 de septiembre, la tienda de apps listaba 492 apps para la 34.0.4 y 327 para la 35.0.1; en mi prueba se desactivaron dos apps de la tienda que no tenían versión para la 35.
• Tras actualizar aparece el aviso "missing table ‘oc_federated_invites’", que es inofensivo, y un panel nuevo con cuatro comprobaciones de base de datos que fallan, una de ellas falsa.
• Volver a la 34 exige restaurar la copia del volumen y de la base de datos; lo que se escribió después de la copia se pierde.

Qué cambia en Nextcloud 35 antes de actualizar

Nextcloud 35 es la versión que la empresa comercializa como Hub 26 Summer, según su registro de cambios^[1]. La etiqueta v35.0.0 se publicó el 15 de septiembre de 2026 y la v35.0.1 el 24 de septiembre, según las versiones de nextcloud/server^[2]. El primer inicio de sesión tras actualizar enseña un asistente con el nombre Hub 26 Summer.

La nota "Upgrade to Nextcloud 35"^[3] del manual de administración resume los cambios de requisitos:

• PHP: la 8.2 deja de estar soportada; los requisitos del sistema^[4] listan 8.3, 8.4 y 8.5 (recomendada)
• MariaDB: la 10.6 sale del soporte; el mínimo es la 10.11 LTS y se añade la 12.3 LTS
• MySQL: la 8.0 sale del soporte; el mínimo es la 8.4 LTS y se añade la 9.7 LTS
• MySQL 9 o superior: necesita INSTALL COMPONENT 'file://component_classic_hashing'; porque partes del ecosistema aún usan MD5
• Sistemas operativos: Debian 13, Ubuntu 24.04 y SUSE Linux Enterprise 15 SP7 como mínimos

En Docker, el requisito de PHP no te afecta: las imágenes nextcloud:34.0.4 y nextcloud:35.0.1 que probé traen las dos PHP 8.5.11 y Apache 2.4.68. El que sí te afecta es el de la base de datos, que corre en su propio contenedor con la versión que tú elegiste.

Qué trae la 35 según el registro de cambios oficial

El registro de cambios de la 35.0.0 es una lista de cientos de pull requests, sin notas de producto. Estas son las entradas que un administrador nota:

• Comandos nuevos occ db:info, db:size, db:index-usage y db:locks (server#60840)
• Una página de base de datos con comprobaciones en la información del servidor (serverinfo#1130)
• La suite ofimática pasa a ser una app incluida (server#60776), y los ajustes cambian OnlyOffice por Euro-Office (server#59933)
• Diálogo y barra lateral de compartir unificados (server#64114) y permisos por destinatario (server#63902)
• Una página de Teams dentro de la app (circles#2561), comentarios en línea en Text (text#8901) y mapa, búsqueda y recuerdos de viaje en Photos (photos#3485)

Qué necesitas antes de empezar

La regla que no admite excepciones es subir de una en una. El manual de actualización^[5] dice: "You cannot skip major releases". Si estás en la 33, pasa primero a la última 34 y luego a la 35. La imagen de Docker lo impone: su entrypoint.sh compara la versión del volumen con la de la imagen y aborta con "It is only possible to upgrade one major version at a time" si la diferencia es mayor que uno.

Antes de tocar nada, comprueba estas cuatro cosas:

1. Que estás en el último parche de tu versión mayor (34.0.4 cuando escribo)
2. Que la base de datos es MariaDB 10.11 o posterior, o MySQL 8.4 o posterior
3. Que las apps de terceros tienen versión para la 35 (lo verás en el paso 1)
4. Que tienes sitio para una copia completa del volumen y un volcado de la base de datos

Tampoco hay vuelta atrás sin copia. El manual lo advierte en un recuadro: "Downgrading is not supported and risks corrupting your data!". Si todavía no tienes Nextcloud en Docker, empieza por la guía de cómo instalar Nextcloud con Docker.

El entorno en el que lo probé

La prueba usó el mismo patrón que el README de la imagen oficial^[6]: un contenedor de aplicación con Apache, otro que ejecuta cron.php cada cinco minutos, MariaDB y Redis. La etiqueta de la imagen sale de una variable para cambiarla sin editar el fichero. Este es el compose.yaml, sin las contraseñas:

services:
  db:
    image: mariadb:11.8
    command: --transaction-isolation=READ-COMMITTED
    environment:
      MARIADB_DATABASE: nextcloud
      MARIADB_USER: nextcloud
    volumes: [db:/var/lib/mysql]
  redis:
    image: redis:8
  app:
    image: nextcloud:${NC_TAG:-34.0.4}
    depends_on: [db, redis]
    ports: ["127.0.0.1:8080:80"]
    environment:
      MYSQL_HOST: db
      REDIS_HOST: redis
    volumes: [html:/var/www/html]
  cron:
    image: nextcloud:${NC_TAG:-34.0.4}
    entrypoint: /cron.sh
    volumes: [html:/var/www/html]
volumes:
  db:
  html:

Las variables de contraseña (MARIADB_PASSWORD, MYSQL_PASSWORD y las del administrador) van en un fichero .env. El entorno completo lo explica la guía de MariaDB con Docker. Sobre la instalación limpia de la 34.0.4 creé dos usuarias más, un grupo y una carpeta Proyectos con tres textos y un fichero aleatorio de 5 MiB, cuyo SHA-256 guardé.

Esa carpeta quedó compartida con otro usuario y con un enlace público protegido por contraseña. Añadí además un evento por CalDAV, un tablero de Deck y siete apps: Calendar, Contacts, Deck, Notes, Tasks, Duplicate Finder y Account retention. Un script verify.sh comprueba todo eso antes y después de cada cambio: versión, usuarios, suma del fichero, acceso compartido, enlace público con y sin contraseña, evento y tableros. Ejecuté las órdenes de esta guía tal como aparecen, cambiando solo el nombre del proyecto de Compose y el del volumen.

Paso 1: comprobar qué apps tienen versión para la 35

Las apps son lo que más se rompe en una versión mayor, porque cada una declara con qué versiones del servidor funciona. La API pública de la tienda devuelve las apps que tienen alguna versión compatible con una versión concreta del servidor:

curl -s https://apps.nextcloud.com/api/v1/platform/35.0.1/apps.json \
  | python3 -c 'import json,sys; print(len(json.load(sys.stdin)))'
docker compose exec -u www-data app php occ app:list --shipped=false

El 28 de septiembre de 2026 esa consulta devolvió 327 apps para la 35.0.1 y 492 para la 34.0.4. De las disponibles en la 34, 168 aún no tenían versión para la 35. Entre ellas estaban dos de las mías: Duplicate Finder 1.8.1 declara >=28.0.0 <35.0.0 y Account retention 1.17.0, <35.0.0. Deck 1.18.5 también se queda en <35.0.0, pero existe Deck 1.19.0 para la 35.

El manual pide desactivar las apps de terceros antes de actualizar y volver a activarlas después. Primero actualiza las que tengan versión nueva y después desactiva las que no la tienen:

docker compose exec -u www-data app php occ app:update --all
docker compose exec -u www-data app php occ app:disable \
  duplicatefinder user_retention

Paso 2: hacer la copia del volumen y de la base de datos

La guía de copias de seguridad^[7] enumera cinco cosas que conservar: config, las apps personalizadas, data, el tema y la base de datos. En la imagen de Docker las cuatro primeras viven en el volumen montado en /var/www/html, así que la copia se reduce a ese volumen y un volcado:

docker compose exec -u www-data app php occ maintenance:mode --on
docker compose exec -T db sh -c 'mariadb-dump --single-transaction \
  --default-character-set=utf8mb4 -u nextcloud -p"$MARIADB_PASSWORD" \
  nextcloud' > backup/nextcloud-db.sql
docker run --rm -v nextcloud_html:/src:ro -v "$PWD/backup":/dst alpine \
  tar -C /src -czf /dst/nextcloud-html.tgz .

La primera orden pone la instancia en modo mantenimiento para que nadie escriba durante la copia. La segunda vuelca la base de datos con las opciones que da el manual, y la tercera empaqueta el volumen desde un contenedor Alpine de solo lectura. Cambia nextcloud_html por el nombre real del volumen, que Compose forma con el nombre del proyecto.

En mi instancia el volcado ocupó 1,35 MB y el archivo del volumen, 532 MB. La diferencia se debe a que el volumen incluye el propio código de Nextcloud, que la imagen copia ahí en la instalación. Si ya haces copias cifradas con restic, estos dos ficheros son lo que tienes que añadir a la política antes de actualizar.

Paso 3: cambiar la imagen a Nextcloud 35

La actualización en sí es cambiar la etiqueta y recrear los contenedores. El README de la imagen lo resume en docker compose pull y docker compose up -d: el script de arranque detecta que el volumen tiene una versión anterior, sincroniza el código nuevo y ejecuta occ upgrade.

export NC_TAG=35.0.1
docker compose pull app cron
docker compose up -d
docker compose logs -f app

Fija la etiqueta de versión (35.0.1 o 35) en lugar de latest. Con latest, un pull rutinario o una herramienta como Watchtower puede subirte de versión mayor sin copia previa. Este es el extracto relevante del registro del contenedor en mi primera actualización:

Initializing nextcloud 35.0.1.1 ...
Upgrading nextcloud from 34.0.4.1 ...
Updating database schema
Updated database
Disabled incompatible app: deck
Disabled incompatible app: duplicatefinder
Disabled incompatible app: user_retention
Update app deck from App Store
Update successful
Maintenance mode is kept active
The database schema does not match what is expected for the
installed version:
  - missing table 'oc_federated_invites'
The following apps have been disabled:
duplicatefinder
user_retention
Initializing finished

Tres líneas merecen explicación. "Maintenance mode is kept active" aparece porque la instancia ya estaba en mantenimiento por la copia: el actualizador respeta ese estado y no lo quita. En otra instancia que actualicé sin activar antes el mantenimiento, el registro dice "Turned on maintenance mode" y, al terminar, "Turned off maintenance mode".

"Disabled incompatible app: deck" asusta, pero dos líneas después el actualizador descarga Deck 1.19.0 de la tienda y la deja activa. Esa descarga necesita que el contenedor llegue a apps.nextcloud.com; en una instancia sin salida a internet no lo he probado. La tercera línea, la del esquema, tiene su propia sección más abajo.

Paso 4: añadir índices, reparar y quitar el mantenimiento

El manual deja fuera del actualizador las operaciones que pueden tardar en instancias grandes y pide lanzarlas a mano después. Son tres comandos db:add-missing-* y la reparación con migración de tipos MIME:

occ() { docker compose exec -u www-data app php occ "$@"; }
occ db:add-missing-indices
occ db:add-missing-columns
occ db:add-missing-primary-keys
occ maintenance:repair --include-expensive
occ maintenance:mode --off

En mi caso db:add-missing-indices no imprimió nada y los otros dos respondieron Done.. La reparación con --include-expensive hizo desaparecer el aviso "Mimetype migrations available" que la 34 ya mostraba. El último comando devuelve la instancia a los usuarios, y conviene lanzarlo solo después de revisar los avisos de la sección siguiente.

El manual también pide ejecutar cron.php dos o tres veces tras una versión mayor antes de encadenar otra, para que terminen las migraciones en segundo plano. Si tienes un contenedor cron, espera a que pase un par de ciclos. Al lanzar cron.php a mano mientras ese contenedor también lo ejecutaba, obtuve un Duplicate entry 'OCA\Deck\Cron\CardDescriptionActivity' for key 'class_index' en el registro.

El aviso de oc_federated_invites no es un problema

El aviso "missing table ‘oc_federated_invites’" sale en toda actualización de la 34 a la 35.0.1 que he hecho, también en una instancia recién instalada. La causa está en el propio código: la 35 incluye un paso de reparación, DropFederatedInvitesTable, que borra esa tabla si está vacía. Sin embargo, occ db:schema:check, un comando nuevo de la 35, sigue esperándola.

Si la tabla tenía filas, el paso de reparación la conserva. En los dos casos tus datos están intactos, y verify.sh pasó todas las comprobaciones con el aviso presente.

Qué avisos nuevos aparecen después de actualizar

La 35 añade una página de base de datos a la información del servidor, en /settings/admin/serverinfo, con 37 comprobaciones. En mi instancia fallaban 4, y el resumen de occ setupchecks pasó a incluir "Database configuration: 4 database checks are failing":

• Slow query log: el registro de consultas lentas de MariaDB está apagado (slow_query_log a 0)
• Long query time: long_query_time vale 10 y recomienda 2 o menos
• InnoDB log file size: innodb_log_file_size vale 100663296 bytes y recomienda al menos 128 MB
• Replica lag: nivel Alert, "A configured replica is not running", en un MariaDB de un solo nodo sin replicación configurada

Las tres primeras son ajustes por defecto de la imagen de MariaDB, y la cuarta es una falsa alarma: no hay ninguna réplica configurada. Ninguna impide usar Nextcloud. Si quieres dejar el panel en verde, los tres ajustes van en un fichero de configuración de MariaDB montado en el contenedor db.

Los comandos occ nuevos también dieron sorpresas. occ db:info marca CHECK en el buffer pool de InnoDB (0,13 GB frente a "≥ 1 GB"). occ db:locks responde que el usuario de la base de datos necesita el privilegio PROCESS. occ db:index-usage falla en MariaDB 11.8 con un error de sintaxis SQL 1064: su consulta usa reads como alias de columna, y READS es una palabra reservada en MariaDB y MySQL.

Qué pasa con las apps que no tienen versión para la 35

El actualizador desactiva las apps incompatibles y te deja un registro de cuáles fueron. Si intentas activarlas después, Nextcloud se niega:

$ occ app:enable duplicatefinder
App "Duplicate Finder" cannot be installed because it is not compatible
with this version of the server.

El registro de Nextcloud da el motivo exacto: "Server version 34 or lower is required". occ app:enable --force user_retention activa la app de todas formas, y en mi prueba los archivos siguieron sirviéndose. No lo recomiendo en producción: la app no se ha probado con la 35 y un fallo suyo puede romper páginas enteras. La opción segura es esperar a que el autor publique una versión o sustituir la app.

Qué pasa si sigues en MariaDB 10.6

La 35 no se niega a actualizar sobre MariaDB 10.6, aunque ya no la soporte. Monté una segunda instancia 34.0.4 sobre mariadb:10.6 y la subí a la 35.0.1: el registro terminó en "Update successful" sin ningún error. El único rastro está en las comprobaciones de configuración, con nivel informativo y no de aviso:

ℹ Database version: MariaDB version 10.6 detected, this version is
end-of-life and only supported as part of Ubuntu 22.04. MariaDB
>=10.11 and <=12.3 is suggested for best performance, stability and
functionality with this version of Nextcloud.

Que funcione no significa que esté soportado, así que sube MariaDB igualmente. En la imagen oficial, cambia la etiqueta a mariadb:11.8 y añade MARIADB_AUTO_UPGRADE: "1". Según la documentación de la imagen de MariaDB^[8], esa variable ejecuta mariadb-upgrade al arrancar y antes guarda una copia de la base de datos del sistema. En mi prueba la comprobación pasó a verde con "11.8.9-MariaDB".

Cómo volver a Nextcloud 34 si algo falla

Volver a la imagen anterior sin restaurar no funciona. Al arrancar nextcloud:34.0.4 sobre el volumen ya actualizado, el contenedor sale con código 1 y este mensaje:

Can't start Nextcloud because the version of the data (35.0.1.1) is
higher than the docker image version (34.0.4.1) and downgrading is not
supported. Are you sure you have pulled the newest image version?

La vuelta atrás consiste en vaciar el volumen, restaurar el archivo, recrear la base de datos desde el volcado y arrancar con la etiqueta anterior. La guía de restauración^[9] pide borrar y recrear la base de datos antes de importar el volcado. Estas órdenes restauran los dos ficheros de la copia:

docker compose stop app cron
docker run --rm -v nextcloud_html:/dst -v "$PWD/backup":/src:ro alpine \
  sh -c 'find /dst -mindepth 1 -delete &&
  tar -C /dst -xzf /src/nextcloud-html.tgz'
docker compose exec -T db sh -c 'mariadb -u root -p"$MARIADB_ROOT_PASSWORD" \
  -e "DROP DATABASE nextcloud; CREATE DATABASE nextcloud
  CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;"'
docker compose exec -T db sh -c 'mariadb -u nextcloud \
  -p"$MARIADB_PASSWORD" nextcloud' < backup/nextcloud-db.sql

Después vacía Redis, que guarda sesiones y bloqueos de la versión 35, y arranca con la etiqueta anterior:

docker compose exec redis redis-cli FLUSHALL
NC_TAG=34.0.4 docker compose up -d app cron
occ maintenance:mode --off
occ maintenance:data-fingerprint

La instancia arranca en modo mantenimiento porque el config.php de la copia se guardó con el mantenimiento activo, así que hay que quitarlo a mano. maintenance:data-fingerprint avisa a los clientes de escritorio de que el servidor volvió a un estado anterior, para que recuperen archivos en vez de borrarlos. Tras la restauración, verify.sh pasó todas las comprobaciones: versión 34.0.4, usuarios, suma del fichero, compartidos, enlace público, evento y tableros. Las apps quedaron como en la copia: Deck 1.18.5 activa y las dos incompatibles desactivadas, porque las desactivé antes de copiar.

Lo que no vuelve es lo que los usuarios escribieron entre la copia y la restauración. Por eso la copia se hace con el mantenimiento activo y la ventana entre copia y verificación debe ser corta.

Preguntas frecuentes

¿Puedo pasar de Nextcloud 33 a 35 directamente?

No. La imagen de Docker compara la versión del volumen con la suya y se niega a arrancar si la diferencia es de más de una versión mayor. Actualiza primero a la última 34, deja que pasen unos ciclos de cron y repite el proceso hacia la 35.

¿Hace falta desactivar las apps de terceros antes de actualizar?

El manual lo pide, y el actualizador desactiva de todas formas las que no declaran compatibilidad. Desactivarlas tú antes te da el control: sabes cuáles son y las revisas una a una. Las que tienen versión nueva en la tienda, como Deck, se actualizan solas durante el proceso si el contenedor tiene acceso a internet.

¿Tengo que actualizar PHP para Nextcloud 35?

En Docker no, porque PHP va dentro de la imagen: tanto nextcloud:34.0.4 como nextcloud:35.0.1 traen PHP 8.5.11. El requisito que sí te toca revisar es la versión de MariaDB o MySQL, que corre en su propio contenedor.

Conclusión

Actualizar Nextcloud 34 a 35 en Docker es cambiar una etiqueta, pero la preparación es lo que decide si sale bien. Comprueba en la tienda qué apps tienen versión para la 35, haz la copia con el mantenimiento activo y fija la versión mayor en el compose.yaml. Después lanza los comandos db:add-missing-* y la reparación, y revisa los avisos antes de abrir la instancia. El aviso de oc_federated_invites y la alarma de réplica son ruido; una app desactivada no lo es.

Ensaya la vuelta atrás al menos una vez antes de necesitarla. En mi prueba, restaurar el volumen y la base de datos devolvió la instancia a la 34.0.4 con todos los datos. Es el único camino, porque la imagen se niega a arrancar una versión anterior sobre datos nuevos. Si vienes de otra actualización de este tipo, la de Jellyfin 12 con Docker sigue el mismo esquema de copia, etiqueta y verificación.

Fuentes: [1] Nextcloud 35: notas de actualización a la 35^[3], [2] Nextcloud 35: cómo actualizar^[5], [3] Nextcloud 35: copias de seguridad^[7], [4] Nextcloud 35: restaurar una copia^[9], [5] README de la imagen nextcloud/docker^[6], [6] Registro de cambios del servidor Nextcloud^[1], [7] Versiones de nextcloud/server^[2], [8] Requisitos del sistema de Nextcloud 35^[4], [9] API de la tienda de apps de Nextcloud para la 35.0.1^[10], [10] Variables de entorno de la imagen de MariaDB^[8].

Fuentes

1. registro de cambios
2. versiones de nextcloud/server
3. nota "Upgrade to Nextcloud 35"
4. requisitos del sistema
5. manual de actualización
6. README de la imagen oficial
7. guía de copias de seguridad
8. documentación de la imagen de MariaDB
9. guía de restauración
10. API de la tienda de apps de Nextcloud para la 35.0.1