Unable to destroy LXC container after CloudPanel installation (Logical volume contains a filesystem in use)

[nethub]

Hi all,

Although we are fully aware that CloudPanel does not officially support LXC containers, one of our clients installed it inside a non-nested CT without our knowledge. This is completely out of our administrative control, and we are now passively dealing with the aftermath.

The main issue is that after this installation, the container becomes impossible to delete via standard Proxmox commands. The pct destroy command fails because the logical volume remains locked, likely due to persistent mounts or leaked processes created by CloudPanel that survive container termination.

We would highly appreciate it if anyone could share a reliable solution or workaround to force-purge this container. While rebooting the PVE node can temporarily clear the lock, doing so every time is difficult for us as it affects all other live clients on the server. Since this situation might happen again, we are looking for a permanent solution or a specific command sequence to safely force-release and destroy this CT directly from the host without requiring a full server reboot. Thank you in advance for your time and help!

Steps to Reproduce:​

1. Create a standard LXC container (e.g., ID 101) without nesting enabled.
2. Enter the container:
   
   

   pct enter 101

   
   
3. Install CloudPanel using their official script:
   
   

   apt update && apt -y install curl wget sudo
   curl -sS https://installer.cloudpanel.io/ce/v2/install.sh -o install.sh
   DB_ENGINE=MYSQL_8.4 bash install.sh

   
   
4. Exit the container and attempt to destroy it:
   
   

   pct stop 101
   pct destroy 101

Expected Result:​

The container stops completely, and pct destroy successfully removes the container and its associated storage.

Actual Result:​

The destruction fails with the following error:

lvremove 'pve/vm-101-disk-0' error:   Logical volume pve/vm-101-disk-0 contains a filesystem in use.

Environment Info:​

• PVE Version: 9.2.3
• Storage Type: LVM-Thin

 

[gfngfn256]

What does this output?

grep pve/vm-101-disk-0 /proc/*/mounts

 

[nethub]

Please find attached the output generated from running the command below:

grep vm--101--disk--0 /proc/*/mounts

 

[gfngfn256]

Please find attached the output generated from running the command below:

I assume from the numerous results that the output you have provided, is while the CT101 is active. AFAICT this is still extremely excessive & unusual.

You need to first stop CT101 & then check that output again. After that, you need to kill those processes still "leaking" from the CT & then you should be able to destroy the CT.

 

[nethub]

Thank you @gfngfn256 .

When we stopped CT 101, the system output showed nothing except: grep: /proc/3063837/mounts: Invalid argument.

We believe this issue is highly similar to the one reported in this thread: https://forum.proxmox.com/threads/logical-volume-pve-vm-101-disk-0-in-use.120999/. In that case, users also had to restart the node to resolve it, which is what we are hoping to avoid with a more permanent solution.

 

[gfngfn256]

When we stopped CT 101, the system output showed nothing except: grep: /proc/3063837/mounts: Invalid argument.

So maybe try:

kill -9 3063837
# replace above '3063837' with the relevant result at the time

pct destroy 101

I must still tell you, I have never seen an LXC (even running) produce such "messy" output on /proc/*/mounts before. This should be concerning to you. Maybe it is privileged? I've never tried that & would not.

 

[nethub]

Thank you for your help.

We cannot simply run kill -9 on that PID because we verified that that PID actually belongs to a completely different CT.

For reference, the affected CT is unprivileged and has nesting disabled.

In fact, this issue can be easily reproduced from scratch by creating a new CT with these exact specs and installing CloudPanel, as detailed in our first post.

 

[leesteken]

Why is nesting disabled, as it is the new default and it's needed by more and more distro templates? Does enabling prevent this issue? I understand if you don't feel like discussing this here and now as you have a more pressing issue with this container.

 

[nethub]

leesteken, thank you for your reply.

As we are a hosting provider, we generally keep nesting disabled by default for better security isolation and to minimize container escape risks on our production nodes.

We actually tried enabling nesting just now to see if it would help release the lock, but unfortunately, it still cannot fix this problem and we still cannot destroy the container.

Since we cannot find a way to resolve this filesystem lock once it happens, we think we will simply have to always enable nesting for future container creations to avoid this mess.