So apps stopped working one by one today, so I jumped into main to take a look - and my cache / SSD has been moved to read only and to unassigned devices, though still shows as cache. See attached screenie. I have rebooted with no discernible change (and restarted the array). I have since moved the array to maintenance mode and tried check filesystem status - just receiving the following error -

ERROR: not a regular file or block device: /dev/ ERROR: cannot open file system Opening filesystem to check...

Clicking on the pencil icon in main on the unassigned device and it will throw up an option to rename the device as follows -

Disk Label: 

Changing the Mount Point will also change the disk label on all disks and the pool name on a ZFS disk.

But been a bit wary there.

It wasn't the world's greatest SSD - so it could be corrupt or dead - but to note, it wasn't heavily used as for whatever reason I couldn't get arr suite to download to the cache and the automatic mover to move the files to the array, (it just slowly filled up and I had to manually move to the array) so it wasn't heavily trafficked or used barely at all for many months.

Screenie of main and logs attached. Any help in a fix or confirmation of dead drive appreciated, I do have a brand new 1TB SSD ready to go.

tower-diagnostics-20260108-1530.zip

For the record, I have since tried to remove the partitions in main - this had no effect.

I have also tried to 'format the unmountable disk' also did nothing. Just refreshed the GUI. I have also tried toggling the auto-mount option from the gears menu in unassigned disk drives - no change.

Edited January 8Jan 8 by sihorrocks

The device dropped offline and reconnected. Replace both cables, then reboot the server and post new diags after array start.

25 minutes ago, JorgeB said:

The device dropped offline and reconnected. Replace both cables, then reboot the server and post new diags after array start.

Thanks - can you specify which two cables? Power / Ethernet / HDD?

There are only two cables that connect to the SSD, power and SATA.

13 hours ago, JorgeB said:

There are only two cables that connect to the SSD, power and SATA.

Thanks heaps. Don't have a spare SATA cable to hand, will take me a day or two to find one, and I am all out of spare HDD power connectors on the PSU - so can't replace that cable realistically without purchasing a brand new PSU. However, the SSD is on an adaptor - this could be the source of issues. Though the other HDDs daisy chained off this were not affected.

Any other options to test? For instance, I could replace the existing SSD with a brand new one I have to hand (using the same cables)

1 hour ago, sihorrocks said:

I am all out of spare HDD power connectors on the PSU - so can't replace that cable realistically without purchasing a brand new PSU. However, the SSD is on an adaptor - this could be the source of issues.

Do you mean a power splitter?

MOLEX-SATA splitters are better than SATA-SATA splitters.

Ideally, no more than 4 drives per PSU cable.

No - a power extension to get the SSD's power cable around the large case to the SSD mounting slot.

Reconnected the original cables, and it has removed the cache from unassigned devices now. So that is an improvement. But looks like all application data has been lost, and my VM won't start. See Screenies. Still getting the unmountable no File System error on the cache in main.

Attached - VM error, cache in main, cache details and exported logs following a reboot and restart of the array (not in maintenance mode).

tower-diagnostics-20260109-1436.zip

Disable Docker and VM Manager in Settings until you get cache fixed.

I said that assuming your Docker/VM related shares (appdata, domains, system) were on cache. But I see you had configured them to not use cache. Ideally, these shares would have all files on fast pool with nothing on the array so Docker/VM will perform better, and so array disks can spin down since these files are always open.

Also, your docker.cfg has

DOCKER_IMAGE_FILE="/mnt/user/docker.img"

This path is at the root of User Shares, so not actually in any user share. No way to know what drive that might be on without inspecting them all. (also, 100G is probably more than you need for docker.img)

Having said all that, go ahead and disable Docker and VM Manager. We can work on your share configuration after you get cache fixed.

https://docs.unraid.net/unraid-os/using-unraid-to/manage-storage/file-systems/#checking-a-file-system

See if a scrub will work on cache.

Thanks mate - I will run through all of that, and come back to you.

Re apps - yeah I moved them off cache, as I noted earlier, it was filling up with files and mover would not automatically move them off, so just ended up with my apps switching off all the time because the cache was full. In the end, having functioning apps (running not on the cache) than apps that weren't functioning was more important. I could not get to the bottom of why my mover wasn't doing anything, so just left them off - performance didn't ever seem impacted for what I needed.

The VM is for running Home Assistant from the Space Invader all in one package, don't recall if I manually made that setting change to the user share or if i was just following his instructionals.

Results of the check filesystems attached - I am no expert but looks like a lot or errors there. Ran in maintenance mode.

Scrub wouldn't run - no btrfs drive mounted. Ran in normal mode.

parent transid verify failed on 307.txt

Edited January 9Jan 9 by sihorrocks
Mistake again

Those shares I mentioned should not be moved, and nothing can move open files anyway. And your docker.img was probably unnecessarily taking too much space. And we don't even know which drive docker.img is on since you put it at the root of user shares.

Personally, I would reconsider other shares and whether to cache them, instead of running my dockers/VMs on the array.

Just now, trurl said:

Those shares I mentioned should not be moved, and nothing can move open files anyway. And your docker.img was probably unnecessarily taking too much space. And we don't even know which drive docker.img is on since you put it at the root of user shares.

Personally, I would reconsider other shares and whether to cache them, instead of running my dockers/VMs on the array.

Thanks for the advice - much appreciated!

Did you try this?

• Replace X with the disk number.

• For drives not in the array: btrfs check --readonly /dev/sdX1

root@Tower:~# btrfs check --readonly /dev/sdb

Opening filesystem to check...

No valid Btrfs found on /dev/sdb

ERROR: cannot open file system

root@Tower:~#

The disk number is three digit code in parenthesis on the array devices list yeah?

I added in the '1' and got the output (begin a dumbass here) - copied to notepad file

ref mismatch on [700186624 16384] e.txt

SMART report for cache doesn't look that good. You should probably replace it.

How important is the cache data?

As we've discussed, pretty much everything is on the array proper, if I lose some app settings I can rebuild them (not ideal but only a couple of hours work) and i have a nicer 1tb SSD in the packaging here that I would happily swap out for.

It was a cheap chinese drive so I am not totally surprised.

According to your diagnostics, domains user share is all on disk3, and isn't configured to have anything on cache, so that is where I would expect your HA vdisk to be. Or did you have some of domains on cache and now it is gone? If it was ever on cache, just setting that share to not use cache wouldn't move it, it would just make it not put new files there.

You should have been seeing SMART warnings (👎) on Dashboard for cache, maybe for some time, and probably had some notifications in the webUI about that as well.

Do you have Notifications setup to alert you by email or other agent as soon as a problem is detected?

1 minute ago, trurl said:

You should have been seeing SMART warnings (👎) on Dashboard for cache, maybe for some time, and probably had some notifications in the webUI about that as well.

Do you have Notifications setup to alert you by email or other agent as soon as a problem is detected?

No agent setup for additional alerts, def seen the odd smart error but I thought only on the array itself not cache - but tbh I built it from HDDs I have had knocking around for years so I was expecting errors with an expectation of them slowly giving out. The server is for media storage (that I don't care about losing) and to recycle/reuse all my old drives until death, so i expect them to die at some point - but the SSD was bought new for the build.

15 minutes ago, trurl said:

According to your diagnostics, domains user share is all on disk3, and isn't configured to have anything on cache, so that is where I would expect your HA vdisk to be. Or did you have some of domains on cache and now it is gone? If it was ever on cache, just setting that share to not use cache wouldn't move it, it would just make it not put new files there.

I moved everything off cache because it just kept filling up - mover wouldn't work, i couldn't fix my issue with it.

18 minutes ago, sihorrocks said:

I moved everything off cache because it just kept filling up - mover wouldn't work, i couldn't fix my issue with it.

As mentioned, nothing can move open files, not even mover. So if you had any of those Docker/VM related shares on cache, you would have to disable Docker and VM Manager in Settings to work with those.

And you really don't want to move them anyway.

Can you see your HA vdisk in the domains share? Or is it gone? Was that working while cache was working?

Mover does work if things are configured correctly. I see you have the mover tuning plugin installed. Good idea to remove that at least until you have things working correctly and moving normally. I personally don't use that and never saw a need for it if you have things setup well.

None of your user shares are currently configured to be moved. That doesn't necessarily mean they didn't have any files on cache.

33 minutes ago, sihorrocks said:

I moved everything off cache

How did you do this? Are you sure everything was off cache?

15 minutes ago, trurl said:

As mentioned, nothing can move open files, not even mover. So if you had any of those Docker/VM related shares on cache, you would have to disable Docker and VM Manager in Settings to work with those.

And you really don't want to move them anyway.

Can you see your HA vdisk in the domains share? Or is it gone? Was that working while cache was working?

yeah everything was working fine (well good enough noting mover never worked) until the cache died and I posted this thread. I don't know how to look for the vdisk in a domains share. I just followed the space invader setup instructions - it worked and I have been using HA ever since.