Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đang mở
  • Có gì không ổn?
#1,021 1 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
65/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
docker, kubernetes, php
Lĩnh vực
devops, infrastructure

Hướng nghiên cứu

Bắt đầu với DockerActions.php:138 và :81-88, sau đó kiểm tra các đường dẫn xóa trong Unregister.php:106 và :135-139, ExAppsPageController.php:494-500 và AppAPIService.php:806/809. So sánh các đường dẫn này với cách xử lý nhãn instance trong haproxy_agent.py:2374. Hoàn thành khi các container và volume Docker mang danh tính instance và thao tác xóa từ chối xóa các tài nguyên thuộc về một instance khác, đồng thời vẫn giữ nguyên việc dọn dẹp của cùng instance.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
PHP
Star
199
Fork
26
Merge trung bình
1 ngày 17 giờ
Pull request đã merge (30 ngày)
47

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của nextcloud/app_api

Tất cả issue của nextcloud/app_api

Issue tương tự

Thêm issue về PHP

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.