MowMdown

Reboot would have done the same thing. Unraid is installed fresh into ram every startup so there is no functional difference between a reboot and a shutdown.

No. Parity and the array will just be out of sync, you would either have to rebuild the drive trusting parity is correct (cant verify) OR Sync parity to the current data.

Click on the disk name "Disk1" or whatever the problematic disk is and there will be a repair button. Yours will say "Repair" instead of check

Like I think I said, if a path is kept open for read by something, it will not allow the array to fully stop. That's why I suggested using lsof /mnt/cache/ which you might have to drill down like lsof /mnt/cache/cloud/ to find out if there is a process open on that folder. Then you can run pkill -9 <PID> to try and stop it.

Can you share the backup script?

FYI, any folders created under /mnt/user/<here> area created as "unraid shares" so if you have a container mapped to write data directly to /mnt/user/ a share will be created. Same thing applies if a folder is created at /mnt/poolname/<here> or /mnt/disk#/<here>

There's no point in having a separate pool of a single HDD for "media" use. Either: Add all three HDDs to the unraid array 1 parity + 2 Data disks or Create a single RaidZ1 zpool with all three disks. The caveat with option #2 is you would need to acquire another 18TB disk if you wish to expand the zpool however this can be done 1 disk at a time now for a single vdev. If you wanted to expand adding a 2nd vdev would require a same number of disks as the first vdev.

zfs master plugin is known to cause issues with the hamburger menu/unraid connect icon. (this was supposed to have been fixed though)

Are you signed into unraid connect?

Nope, it's a secure encrypted tunnel. it's a private VPN. The traffic is encrypted between your remote device and the end point (the NAS)

You don't have a choice, zfs is required as the boot partition, and your assumptions about ARC are misplaced. Unraid will not use up 2GB of RAM for ARC on a boot pool which almost never has any read activity going on. furthermore it's dynamic so unraid will evict any ARC memory use if the rest of the system needs it. ARC is read caching for files frequently read, the boot pool never has any reads unless you are editing config files. you will never see ARC memory use. Internal boot is an option, booting off the USB is still valid.

FYI Internal boot and TPM licensing are two completely separate entities. You can use internal boot and keep the USB as the license

It's over tailscale it's secure since it's a private network only you control. HTTP or HTTPS the traffic is encrypted through a wireguard tunnel.

Yeah you have something seriously wrong with your motherboard for this to keep happening on multiple USB drives. USB drives while not know for their longevity, do not just die after a few bytes are written... Also when these USBs "die" are they detectable in other systems? Like can you plug them into your pc and read them?

All you have to do with the array stopped is click the disk count dropdown, and set from 1 to 2 and then assign the 2nd disk. Unraid will do its thing and you will have two disks available for use as a boot pool.

While booted from the USB you run the onboarding wizard, this will create a boot pool on the optane disks if you choose them. Then you reboot and it’ll boot from the disks instead of the USB

I wrote a guide for something similar: https://github.com/MowMdown/unraid-local-dns-guide

If you're giving them jellyfin access, why do they even need access to the rest of the server? Their jellyfin client accesses jellyfin server through jellyfin's own backend. They do not need access to SMB or your NAS directly at all...

No unraid does not split data based on size. It doesnt even do caching, it's just writes all data to either a pool or the array first and moved later depending on mover settings. The only real use for the 16GB optane drives are using them as boot pool devices.

@JorgeB Can you take a look at the steps I laid out below and give you input on this? In theory this should work but I dont want to accidentally give any bad advice. @daschmidt These are the steps I believe will achieve what you are asking. However I would caution you to wait to see if Jorge has any critiques or concerns before attempting. Note: you will not be able to use the same pool name since unraid does not allow two pools with identical names. If you want to keep the pool name the same you will need to migrate the data onto the array and then remove the pool entirely. If you want to use a different pool name, you should be able to follow the steps below: Follow the procedure here to remove one of the drives from the pool. Once the drive has been safely removed from the pool, you can create the new boot pool with the single drive using the onboarding wizard. (make sure you pick boot+data option) Cant name it the same as your Then reboot. After the reboot from creating and booting off the single new boot disk, copy the data from the existing pool to your newly created data partition on your boot pool. (I would consider copying it to the array instead) Stop the array again and with the array stopped you can click on the drop-down and make the boot pool 2-disks wide. Add the 2nd disk, select the data partition name, make sure it's btrfs mirror. Start the array. With the array started you will want to click the name of the pool again, and click on "Balance" this should mirror the data between the two disks and get you back to a protected state. Edit: Step #5 is not needed as unraid will automatically do the balance when a 2nd drive is added.

Do you run a backup script or plugin or the flash backup feature from the Management Access page in the settings?

Any reason you don't just select "Container" as the network type and select the container you are networking too?

Post the docker run output please

@Rattenb0y --gpus all has never been accepted on unraid. If you read the official nvidia gpu driver documentation it tells you exactly how to get nvidia gpus working on unraid. --runtime=nvidia goes in extra parameters create two "variables" NVIDIA_VISIBLE_DEVICES=all and NVIDIA_DRIVER_CAPABILITIES=all

Yeah a whole lot of information since that video was released... when it wasn't even in beta yet.