MowMdown

From what I recall this mean FUSE has crashed. Likely caused by whatever else is going bad.

I run 4x SATA SSDs in a RAID10 configuration and have no trouble with speeds.

In my opinion you're better off installing the standard Nextcloud container by Linuxserver

I think you're fundamentally missing a critical thing. You don't NEED tailscale for your individual containers. Simply getting your server on your tailnet is all you need to access ALL your containers via the tailscale IP and the container port. For example if your tailscale IP is 100.106.13.67 and you wanted to access plex, you type in http://100.106.13.67:32400 If you want to take it one step further and have access via your local IP instead of the tailscale IP, you go to the tailscale plugin settings and advertise your router subnet and then approve the subnet on tailscale admin dashboard online. If you want to take it even further see this tailscale dns guide I wrote

If this is the case you’re using Tailscale wrong. The Tailscale plugin is a one and done deal. You authenticate each physical device one time and you can access your entire LAN. So your server, your laptop, your phone all need to be added ONCE. And you’re in. There is nothing to do with containers other consoles/logs. You should NOT be using the little Tailscale toggle that you see on a container template page. If this is too complicated. Unraid has a wireguard VPN manager built in. It does the same thing as Tailscale but a lot more manually. You will need a DDNS for this to keep your public IP updated. Another easy to use option is Cloudflare Tunnels

You formatted your disks that contained data? Do I understand this correctly? Please explain in detail exactly what you mean by this. It sounds to me like you took your existing data disks, put them in your unraid array and formatted them. If that is the case formatting them erased your data. If I’m way off please explain what you were doing prior to the data being erased. To be clear unraid does not erase/delete data unless you tell it to.

Do you have SAS disks? Those are known for not obeying spin down.

use lsof /mnt/disk# to see if anything is keeping it awake. you 100% have a docker container or a plugin reading from a disk.

Likely need to wait until the next unraid release when they introduce the new LTS kernel

Plex is using CPU to transcode here. The absence of it showing "(hw)" next to the video is a key indicator

Once it's done disk4 is going to be unmountable. you will want to shutdown the system and then put disk4 into a windows pc and use UFS explorer to read the disk. If it can read the disk you may be able to copy the contents from the disk to your PC to put back on your NAS

FYI 2026.1.0 is live as a stable update

Yes you need to click on "+Add Device, Port, Variable" at the bottom of the template page and then add a device and pass through/dev/dri Alternatively you can add --device=/dev/dri to the extra parameters field if you toggle the advanced view.

Yes the VM takes control the GPU. The GPU cannot be used on the host machine until after a reboot. This is normal and expected. Not a bug. AMD GPUs allegedly could return to the host using the AMD Vendor reset plugin but I dont have experience with passing through GPUs. Intel GPUs and Nvidia GPUs require a full reboot. Edit: Apparently it can be rare some hardware can handle it but it's going to be highly dependent on the specific hardware combination and drivers.

Yeah this thing is going to struggle with immich. Pinning to a core or two might help but If I were you I would disable all of the machine learning and video conversion settings. The CPU has an iGPU which can handle some of the tasks pretty efficently but not all of immich's tasks can utilize the iGPU and will rely on the CPU which you have very little of. Also you need to configure immich to use the iGPU manually if you have not done so already.

Pretty much yeah

Enable the remote syslog server and post diagnostics next time it happens you might have to ssh in and run the command from terminal diagnostics if you cant access the webgui.

Where are you replicating your snapshots to? Snap-shotting live data is risky and will not guaranteed to be functioning upon a rollback. Think databases. These need to be stopped and dumped to be safely restored. What is your plan if you have more disks fail than a zpool can handle and you lose ALL the data? With the unraid array at most you only lose the data on the failed disks and not the entire array. Do you want ALL your disks spun up and reading/writing 24/7? There is no selective spin down. Do you need more than 200+MB/s read speed on any single given disk? How familiar with zfs filesystem are you? Do you have excess RAM you're needing to put to use? ZFS performs optimally the more RAM you can allocate to it for read caching. It's not a hard requirement but it definitely help to have more RAM for zfs. IMO there is a time and place like using zfs on ssd pools but for HDDs unless you know you need the speed and throughput (enterprise workloads) single disks in XFS is my preferred way to go.

FYI there is a new update 2026.1.0 it’s currently in beta. I attempted the upgrade and for me personally it did not go over smoothly so if you’re gonna update. Make a backup of your container appdata and database. Also to complete the update you need the :8.4 tag for the container. So far it seems to be working now but I started over with a clean slate

This is going to be a process. My suggestion is to consolidate all data onto as few of your disks as possible. You need to at least have two emtpy disks to make this work I believe. With the empty disks, make a pool and add them. Set them as zfs filesystem in RAIDZ1 Yours will say "1 vdev of 2 devices" at first. With that complete. Copy the data from the remaining two array ssds onto the newly created pool. When that is done, you can add the 3rd disk to the pool, once the expansion process is finished you can add the 4th and final ssd to the pool and you will end up with a result like the screenshot where it says "1 vdev of 4 devices" if it goes according to plan.

You would need to have at least a mirror (two drives in raid1) for both your cache and vm pools since they are both only single disks

You probably need to reboot to get rid of the license error message.

mv Trial.key Trial.old Just note that the command is case-sensititve so it might be mv trial.key trial.old

Basically, any share that does has files on a disk pool that is a single disk (or the unraid array without a parity disk) will get reported as being unprotected due to the fact that if one of those disk pools fails, you have no redundancy. (no 2nd drive to act as a failsafe)

Pools use RAID which will provide some level of parity depending on which FS you choose and which RAID level. As you see, RAIDZ1 provides 1 level of parity protection for the pool of drives per VDEV. Given you have 4 disks you would be wise to opt for a single VDEV of 4 disks wide. Yes SSDs in the unraid array are not idea as TRIM is disabled there. Moving to a pool is the wise choice. Absolutely do not use 1SSD per VDEV, that would be illogical. What I would suggest, now that unraid supports single drive RAIDZ1 expansion is to move as much of your data on to as few disks as possible if you can free up two disks or even 3 disks even better. If you cant this likely wont work without moving data to an external drive. You can move the parity disk and the empty data disk and create a RAIDZ1 (not mirror) With two disks in RAIDZ1, you can copy over data from the 3rd disk, then you can add the 3rd disk and expand the RAIDZ1, once that's done you can copy over the rest of the data and then add the now empty 4th disk and then expand the pool again. At the end, you will end up with a single VDEV of 4 disks in RAIDZ1 (you will not have 4 individual vdevs of 1 disk each)