Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Deploy and unregister --rm-data silently destroy another instance's ExApp container and volume when two Nextclouds share one Docker daemon

Abierto
#1,021 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 3 días

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
65/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
docker, kubernetes, php

Línea de trabajo

Comienza con DockerActions.php:138 y :81-88; después, inspecciona las rutas de eliminación en Unregister.php:106 y :135-139, ExAppsPageController.php:494-500 y AppAPIService.php:806/809. Compara estas rutas con el manejo de la etiqueta de instancia en haproxy_agent.py:2374. El trabajo estará terminado cuando los contenedores y volúmenes de Docker lleven una identidad de instancia y la eliminación se niegue a borrar recursos pertenecientes a otra instancia, manteniendo la limpieza de la misma instancia.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

We lost the data volume of a working ExApp because a second Nextcloud instance on the same host uninstalled its own copy of the same app.

Setup: two Nextcloud instances (a real one and a throwaway test instance), each with its own HaRP, both pointing at the same Docker daemon. Container and volume names are built from the app id alone (nc_app_<appid>, nc_app_<appid>_data), so both instances resolved to the same container and the same volume.

Two things happened, and I think both deserve a look:

  1. Deploying the app on instance B force-removed the running container of instance A and recreated it with B's APP_SECRET and NEXTCLOUD_URL (DockerActions.php:138 on the HaRP path, :81-88 on the classic one). A's app was broken from that moment, without any warning.
  2. occ app_api:app:unregister <appid> --rm-data on B then deleted the shared volume. For us that was a search index over 50,000 files, roughly 19 hours of rebuild. Docker's own "volume is in use" protection could not help because step 1 had already removed the container that held it.

None of the removal paths checks who created the container or volume: the occ command (Unregister.php:106 and :135-139), the admin UI (ExAppsPageController.php:494-500), and removing a deploy daemon (AppAPIService.php:806/809), which deletes volumes without any flag at all.

I know about #523 and this is deliberately not another naming ticket: even with an instance prefix in place, existing volumes stay unprefixed and the removal paths still delete blindly. It is also not the multitenancy request from nextcloud/HaRP#49, rather the opposite: we do not want to share a container between instances, we want two independent deployments to stop destroying each other.

A fix that would have saved us, and that looks backportable: set labels on container and volume at create time (for example nextcloud.appapi.instance_id) and make the removal paths refuse when the label points to a different instance. Right now the Docker path sets no labels at all, while the Kubernetes path already sets app.kubernetes.io/instance from instance_id (haproxy_agent.py:2374), so the pattern exists in the codebase.

Observed with Nextcloud 34.0.3, AppAPI with HaRP 0.4.5, Docker on Ubuntu (arm64). Happy to share the full logs with timestamps.

Lenguaje dominante
PHP
Estrellas
199
Forks
26
Merge medio
2 d 6 h
PR fusionados (30 d)
48

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de nextcloud/app_api

Todos los issues de nextcloud/app_api

Issues similares

Más issues de PHP

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.