​

Hi everyone,

I'm trying to recover data from a Nextcloud storage volume after an unexpected failure and I'm running out of ideas. The goal is data recovery only (mostly family photos). I don't care about restoring the container itself.

I found a few older threads with similar symptoms, but my case seems different because the thin metadata and the ext4 filesystem both appear to be intact.

Environment​

• Proxmox VE 8.2.4
• Kernel: 6.8.8-2-pve
• LVM Thin Pool
• One physical disk (8 TB)
• LXC container with an additional mount:

mp2: nextcloud:vm-102-disk-0,mp=/8tbhdd<br>
The thin LV:

/dev/nextcloud/vm-102-disk-0<br>
is no longer activatable.

Error​

lvchange -ay nextcloud/vm-102-disk-0<br><br>device-mapper: reload ioctl failed: No data available<br>
Kernel log:

device-mapper: table: thin: Couldn't open thin internal device (-ENODATA)<br>

Current LVM status​

LV VG Attr<br>nextcloud nextcloud twi---tz--<br>vm-102-disk-0 nextcloud Vwi---tz--<br>
The pool itself exists, but the thin volume cannot be activated.

What I already verified​

1. thin_check​

thin_check /dev/mapper/nextcloud-nextcloud_tmeta<br>
Completes successfully:

examining superblock<br>examining devices tree<br>examining mapping tree<br>checking space map counts<br>
No errors.

2. thin_dump​

The metadata contains the thin device:

&lt;device dev_id="1" mapped_blocks="62120451"&gt;<br>
So Device ID 1 still exists.

3. thin_rmap​

thin_rmap --region 16387..16388 metadata.bin<br>
returns

data 16387..16388 -&gt; thin(1) 0..1<br>
The mappings appear valid.

4. ext4 filesystem​

I manually read the ext4 superblock from the mapped data blocks.

dumpe2fs reports:

• valid ext4 filesystem
• filesystem state: clean
• journal present
• valid UUID
• valid group descriptors
• last mounted: 2026-06-14
• last write: 2026-06-15

So the filesystem itself appears to be intact.

I also manually verified the Group Descriptor Table via dd and the values look correct.

What does NOT work​

lvchange -ay nextcloud/vm-102-disk-0<br>
vgchange -ay nextcloud<br>
DMDE only detects the LVM physical volume but cannot automatically expose the ext4 filesystem because the thin device itself cannot be instantiated.

What I am trying to achieve​

I do not need the container.

I only want read-only access to the ext4 filesystem so I can copy the photos to another disk.

My question​

Has anyone seen a case where

• thin_check succeeds,
• thin_dump contains the thin device,
• thin_rmap resolves mappings correctly,
• the ext4 filesystem is readable,
• but dm-thin still refuses to instantiate the thin device with

Couldn't open thin internal device (-ENODATA)<br>
Is there any way to

• manually activate Device ID 1,
• create a read-only thin device,
• or reconstruct the thin LV from the existing metadata?

I'm happy to provide any additional information (thin_dump, thin_check, lvs, dmesg, dumpe2fs, dmsetup, etc.).

Any ideas would be greatly appreciated. Thanks!