I was trying Unraid with the trial ... everything was running smoothly until today when I realized that my trial expired. I purchased a license, applied it, and then started the array. When it started, the drive that was the cache was included in the list of array devices and the cache was unassigned. I tried to unassign the cache drive from the array drives and then assign it to cache but now when the array starts it shows Unmountable: unsupported or no file system.

Any help would be much appreciated!

Diagnostics: illmatic-diagnostics-20260202-2213.zip

Start the array in Normal (not Maintenance) mode and post new diagnostics.

Attached are new diagnostics illmatic-diagnostics-20260202-2353.zip

What do you get from command line with this?

fdisk -l /dev/sdb

It thinks you still have a missing disk4 and it doesn't know what filesystem cache is supposed to be.

You will have to New Config and rebuild parity to get rid of the missing disk4.

Do you know what filesystem was on cache?

Besides the fdisk output, if the pool was using the default btrfs filesystem also type

dd if=/dev/sdb bs=16M status=progress 2>/dev/null | hexdump -C | grep '_BHRfS_M'

Let it run for a couple of minutes and post any output, you can then abort with CTRL + C

I assume going the new config route won't wipe all the existing data?

I don't remember picking a filesystem type, most likely used the default (auto).

fdisk:

Disk /dev/sdb: 894.25 GiB, 960197124096 bytes, 1875385008 sectors
Disk model: CT960BX500SSD1  
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: 0x3d695629
Device     Boot Start        End    Sectors   Size Id Type
/dev/sdb1        2048 1875385007 1875382960 894.3G 83 Linux

There was no output from the dd command after almost 5 mins.

7 hours ago, JorgeB said:

Besides the fdisk output, if the pool was using the default btrfs filesystem also type

dd if=/dev/sdb bs=16M status=progress 2>/dev/null | hexdump -C | grep '_BHRfS_M'

Let it run for a couple of minutes and post any output, you can then abort with CTRL + C

43 minutes ago, johraid said:

There was no output from the dd command after almost 5 mins.

@JorgeB

Is there a typo in that command?

Command is correct, it suggests either it was formatted with a different filesystem or the device was wiped. Could it be XFS or a different one?

FWIW, I also tried (thought the typo was in BHRfs):
dd if=/dev/sdb bs=16M status=progress 2>/dev/null | hexdump -C | grep '_BTRfs_M'

dd if=/dev/sdb bs=16M status=progress 2>/dev/null | hexdump -C | grep '_BtRfS_M'

But still no output. I don't think I would've changed the filesystem type but would there be something I can do to check if it was xfs?

For XFS you can use:

dd if=/dev/sdb bs=16M status=progress 2>/dev/null | hexdump -C | grep 'XFSB'

If there's also no output, I recommend running UFX Explorer. The free trial should show if it finds any compatible filesystem, the commands I posted will only work if the superblock is still there, it doesn't look for actual data, UFX Explorer can recover data even without the superblock.

So nothing from the XFSB command either. I'm OK if I lose the data at this point, it was just plex metadata that's only a month old so not a big lose ... just wanted to know if there was somehing inherently wrong with the set that would've caused this.

I'll format the drive and set it up again for cache. Going back to the new config, the data will persist through the use of the tool?

Edited February 3Feb 3 by johraid

Disable Docker in Settings until you get cache going again.

Then we will have to work on the related shares - appdata, system - since they are on the array

Ok, formatted and assigned the drive to the cache. app data is already set to using cache. system is currently set to use the Array. OK to just switch that to cache? If I move system to cache and this happens again, would that be a bigger issue? I only have 1 cache drive.

3 minutes ago, johraid said:

app data is already set to using cache

But it has some files on the array. Just settting it to use cache won't move any files that were already on the array. And since there is no Secondary there is no Mover action so they won't be moved.

4 minutes ago, johraid said:

If I move system to cache and this happens again, would that be a bigger issue?

No, docker.img is easily recreated and often required when troubleshooting docker service.

Ideally, appdata and system shares would have all files on cache or other pool with nothing on the array, so Docker will perform better and so array disks can spin down since these files are always open. Similar for domains share if you were using VMs.

Nothing can move open files. Disable Docker in Settings so these can be worked with.

Then set appdata and system shares to Primary:cache; Secondary:array; Mover action:array->cache

Then click Move in Array Operation, wait for it to complete, post new diagnostics.

Thanks for all the info and help!! Here are the new diagnostics after the move operation completed: illmatic-diagnostics-20260203-1529.zip

Edited February 3Feb 3 by johraid

That looks good.

Now

https://docs.unraid.net/unraid-os/troubleshooting/common-issues/docker-troubleshooting/

Ok, went through that guide and I have plex up and running again. Thank you!

I think now my last issue is the empty device in my array:

Is this the guide I should follow to fix? https://docs.unraid.net/unraid-os/using-unraid-to/manage-storage/array/removing-disks-from-array/#removing-data-disks

Do a new config (Tools - New Config - Keep All - Apply) then check "parity is already valid" start the array, and run a correcting parity check; some errors are expected.

Just got through the parity check and looks like everything is back to how it was. Thank you!!