Thin LV cannot be activated (-ENODATA) despite valid metadata and readable ext4 filesystem

cesa01

New Member
Jul 11, 2024
1
0
1

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!