I have a ZFS dataset that seems to have gone into limbo i.e all the files are not reachable.  Looking at the GUI it appears to have 3.6GB still sat in it but I cannot see the files, destroy the dataset, rename it or unmount it.  I'd like to get all the files back if possible:

 

 

Trying to see the files in the GUI:

 

 

Or from CLI:

 

GUI Destroy (with force) yields:

 

GUI Rename:

 

 

zfs list

 

Also tried disabling Docker service and running above - it didn't help.

 

disk2 was recently scrubbed and has no errors.

 

I'm now running Unraid v7 but issue was also there in v6

 

Diags attached

 

Any help to get the files back would be appreciated.

 

Thanks

 

ding-a-ling-diagnostics-20250111-1228.zip

Edited January 11, 20251 yr by late4473
Typo

Unraid doesn't create nested datasets, how was that created?

Via the Gui (ZFS Master)

Post the output from:

zfs mount

and

zfs get all disk2/media/photo-other

 

Both Attached. Thanks!

mount.txt getall.txt

Not seeing anything out of the ordinary, see if you can replicate that dataset to another one on the same disk, or a different zfs disk or pool, with zfs send/receive

zfs snapshot disk2/media/photo-other@now

zfs send -R disk2/media/photo-other@now | zfs receive pool_name/destination/dataset/name

 

It replicated fine!  All 3.6GB.  And I CAN see the files!  Great news - thank you.

 

 

But how do I now delete the original Dataset on disk 2?

 

I have set the immutable flag in the past on the photo-other folder - but as far as I can see this is clear on Disk 2.  Does this give a clue?

 

 

Another clue perhaps - destroy cmd from CLI.  This was after manually creating a normal folder /mnt/disk2/media/photo-other so that 'something' existed.

 

Edited January 11, 20251 yr by late4473
Background

Try this:

 

zfs set -o canmount=off disk2/media/photo-other  

 

Then reboot and try zpool destroy again

Didn't like the -o

 

 

And without:

 

 

Sorry, typo, does the dataset still show up under zfs list?

NP

 

Yes it does:

 

I'm afraid that I don't have any other ideas, if replication got the data back, just ignore that dataset, or backup and re-format the complete disk.

Thanks for your help.

 

I'm convinced I've set something 'immutable' - I just cannot find what.

 

I hope no more datasets go this way!

To close on this - it WAS to do with an immutable flag...it was just hidden

 

I ended up copying all the data out of my media share and I was left with 2 shares that still had 'operation not permitted' when I tried to destroy them:

 

media/Movie

media/photo-other

 

'media' was an encrypted datashare whereas the nested 'media/photo-other' was not (just saying)

 

I 'unlocked' media via the GUI and this gave a failure message and still showed the open padlock...but magically this enabled me to see the files in photo-other and:

 

So the 'masked' files were immutable preventing actions noted in the OP.  So I cleared the flags, deleted the files, then destroyed the datasets.

 

The take away message: take care with encrypted dataset where you (accidentally or otherwise) create files and folders whilst it is locked!

 

I just glad this wasn't a bug where ZFS had let me down.  I'd written my files whilst the dataset was locked, so after my weekly reboot and the dataset was unlocked (via a script on array startup) all my files appeared to disappear - and because I had made them immutable (ransomware protection) the dataset couldn't be destroyed!  Confusing but explainable.

 

Cheers all.