Panelica Community Forum
Welcome to the official Panelica Community Forum — the central hub for server administrators, developers, and hosting professionals. Register a free account today to access technical discussions, product announcements, feature requests, and direct support from the Panelica team. Be part of the growing community shaping the future of server management.
Solved Docker container delete problem
- Thread starter tailadmin
- Start date
Could you please explain in detail what steps you took to investigate this issue? We were unable to identify or reproduce this issue on our side.
PostgreSQL konteynırım vardı. Rutinde tüm web sitelerim bunu kullanıyor. Daha sonra Iot cihazlarım için emqx konteynırı aktif etmek istedim, listede bulamadım, yaml dosyası olarak çalıştırdım fakat dökümantasyonundaki talimatı direk yapıştırdığım için expose port ayarları olmadan çalıştı. Bende manuel docker run ile çalıştırmak istedim. Bunu yapmadan öncede mevcut emqx konteynırını silmek istedim. O anda emqx ve postresql iki tane konteynır vardı ekranda. Sadece emqx'i seçip sil düğmesine bastım fakat silinmedi. Hatada vermedi ama silme işlemini Delete Selected düğmesi ile yapmıştım. Dedim ki o düğme çalışmıyor olabilir o zaman alttaki çöp kutusu simgeli sil düğmesine tıklayayım, onu tıkladığımda ikisi birden silindi ve tüm veritabanım yok oldu. Tabi düşünmeden hemen yeniden bir postgresql kaldırdım, oda init çalıştırdığı için önceki konteynıra ait data klasörünü silmiş oldu ve bu sayede tüm veritabanımı kaybettim, taşıma sırasında aldığım db yedeklerine geri döndüm. Panelin yedekleme kısmı docker üzerindeki db leri kapsamadığı ve default olarak postgresql ayrıca sunulmadığından projelerime laravel commands ile çalışan yedekleme job ları oluşturdum, günlük kendi yedeğini alır hale getirdim.
Kritik konteynırlar için deploy'un içindeki enviromentteki gibi kilitleme işlemi olabilir, kilit açılmadan silinemez ve x tane kontynır silinecek bildirimin haricisnde koteynır isimleri tek tek yazabilir ve DLETE yaz kutusundaki metin DELETE-KONTYNIR ADI olabilir, hatalı silme konusunda kullanıcıya evet şuan postgresql'i siliyorum galiba durmalyım farkındalığını net sağlar diye düşünüyorum. UX lik bir durum bu önerim. Yedekleme sistemine docker'ın datasınıda tanımlayabilirsek mysql gibi postgresql desteği ayrıca sunmak gerekmeyebilir, mongo vs. diğerleride alınabilir veya bu benim docker bilgisi eksikliğimde olabilir bilmiyorum. data klasörü direk data değilde konteynır id'si ile oluşturuylsa initte eskisi silinmez. geri getirilebilir olur.
Hello, and thank you for your feedback. We were able to reproduce the issue exactly as described and have resolved it.
During our investigation, we identified two separate issues and addressed both:
1) The "Delete All" button could be confused with the individual delete action.
The "Delete All" button above the container list was previously displayed only as a trash-bin icon, making it very similar to the delete icon used for individual containers. This could result in accidentally clicking the bulk-delete button when intending to delete a single container.
We have now clearly separated these actions. The bulk-delete button is displayed with a prominent warning icon and a visible "Delete All" label. In addition, the existing type-to-confirm step remains in place to prevent accidental deletion.
2) Data protection has been hardened — this was the actual root cause.
When deleting an individual container, the data directory under <span>/home/user/docker/</span> could previously be removed even when the delete volume option was not selected. If two containers were using the same volume name, deleting one of them could therefore affect the data of the other container due to the name collision.
We have addressed this at three levels:
The fix will be included in the next panel update. Once you have updated the panel, could you please try the operation again?
If you experience any further issues, simply let us know here and we will be happy to investigate.
During our investigation, we identified two separate issues and addressed both:
1) The "Delete All" button could be confused with the individual delete action.
The "Delete All" button above the container list was previously displayed only as a trash-bin icon, making it very similar to the delete icon used for individual containers. This could result in accidentally clicking the bulk-delete button when intending to delete a single container.
We have now clearly separated these actions. The bulk-delete button is displayed with a prominent warning icon and a visible "Delete All" label. In addition, the existing type-to-confirm step remains in place to prevent accidental deletion.
2) Data protection has been hardened — this was the actual root cause.
When deleting an individual container, the data directory under <span>/home/user/docker/</span> could previously be removed even when the delete volume option was not selected. If two containers were using the same volume name, deleting one of them could therefore affect the data of the other container due to the name collision.
We have addressed this at three levels:
- When deleting an individual container, its data directory is never touched if volume deletion is not explicitly selected.
- Even when volume deletion is explicitly requested, the directory is preserved if another container is still using the same directory.
- For newly created containers, bind paths are now isolated by the container/stack name: <span>/home/user/docker/{name}/{volume}</span>. This makes volume name collisions structurally impossible.
The fix will be included in the next panel update. Once you have updated the panel, could you please try the operation again?
If you experience any further issues, simply let us know here and we will be happy to investigate.