How do I reattach a disk to LCX container

Evocati

New Member
Jul 31, 2025
7
2
3
Hi,

I encountered the following error when trying to start an LXC container:
  • TASK ERROR: startup for container '101' failed
I identified that one of the disks was full, so I detached the full disk and was then able to start the LXC container.

Now, please, how can I reattach it without losing any data?

1753920153872.png
 
Try to shut the CT down and see if it works then.
Unrelated but something strange is going on with your theme. The text is basically unreadable. Maybe some browser extension interfering?
1754155872540.png
 
Last edited:
Thanks, I forgot that important detail , and I already turned off the extension.

I managed to create it, but now I can't start the CT.

1754156462818.png
 
Hmm, I don't think you can attach a VM virtual disk to a CT just like that. The VM virtual disk is probably partitioned and a CT does not support that. Maybe copy mount the VM virtual disk manually (by adding an offset to the right partition; there are guides on the internet for this) and copy the files to a new CT virtual disk?

EDIT: Please note that sharing a virtual disk between VMs and/or CTs are the same time will cause corruption and data loss as the operating systems and filesystems are not designed for that.

EDIT2: I might be completely wrong about the virtual disk belonging to a VM, sorry.
 
Last edited:
  • Like
Reactions: Evocati
I didn't know this was once a VM disk. Maybe I missed a mention of that? The PVE naming scheme doesn't help here.
Try pvesm path ... to get the path to the raw file and then check fdisk -l PATHHERE and file PATHHERE.
A CT disk can look like this
Bash:
# file /var/lib/vz/images/101/vm-101-disk-0.raw
/var/lib/vz/images/101/vm-101-disk-0.raw: Linux rev 1.0 ext4 filesystem data, UUID=0c605789-9962-403a-9532-2b87943ffa8c (extents) (64bit) (large files) (huge files)

# fdisk -l /var/lib/vz/images/101/vm-101-disk-0.raw
Disk /var/lib/vz/images/101/vm-101-disk-0.raw: 8 GiB, 8589934592 bytes, 16777216 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
A VM disk (A MBR debian install in this case) can look like this
Bash:
# file /var/lib/vz/images/100/vm-100-disk-0.raw
/var/lib/vz/images/100/vm-100-disk-0.raw: DOS/MBR boot sector; partition 1 : ID=0x83, start-CHS (0x4,4,1), end-CHS (0x3ff,254,2), startsector 2048, 21065728 sectors; partition 2 : ID=0x5, start-CHS (0x3ff,254,2), end-CHS (0x3ff,254,2), startsector 21069822, 1996802 sectors

# fdisk -l /var/lib/vz/images/100/vm-100-disk-0.raw
Disk /var/lib/vz/images/100/vm-100-disk-0.raw: 11 GiB, 11811160064 bytes, 23068672 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x18ee74c7

Device                                    Boot    Start      End  Sectors  Size Id Type
/var/lib/vz/images/100/vm-100-disk-0.raw1          2048 21067775 21065728   10G 83 Linux
/var/lib/vz/images/100/vm-100-disk-0.raw2      21069822 23066623  1996802  975M  5 Extended
/var/lib/vz/images/100/vm-100-disk-0.raw5      21069824 23066623  1996800  975M 82 Linux swap / Solaris
Once we know for sure it's a VM disk and not just corrupted or something we can look into further ways to use it. Ideally you attach it to a VM.
You could mount the partition by first using kpartx PATHHERE and then mount /dev/... but I don't think that's a good idea right now.
 
Last edited:
Thanks for the replies and suggestions.

This second disk was already working fine on this Turnkey CT until one day I realized I couldn't access it. It said it was being used by another process. I tried to access the Turnkey CT and couldn't do that either.
So I unmounted the disk and was able to initialize the CT, but if I add it back, I get this last error.

I believe the disk is working fine, and the problem is that it has reached the maximum space quota.
1754159808829.png
Now the most important thing for me would be to recover the data. Any suggestions for the simplest way to copy it to another drive?
 
  • Like
Reactions: leesteken
As it's a file you can just cp or mv it somewhere else. I'd recommend you follow the procedure above first so we can tell what's inside of it.
It's not clear what is taking up the space of the pictured Storage. Use df -hT to find where the disk of it is mounted and then use this to find out

Bash:
apt install gdu
gdu /PATHHERE
 
Last edited:
  • Like
Reactions: Evocati