testdasi

That is typical symptom of wrong share Cache settings. Provide details. For large data transfer, it is almost always better to turn on reconstruct write aka turbo write instead of relying on cache. Is the graphics card the only card in the system i.e. does Unraid also boot with that card? Have you isolated your VM cores? Those are the 2 main reasons causing demonic sound even after msi_utils fix. There are plenty of things that all sorts of mature paying software don't support. Try a set of powerline network adapter if you don't want to run wired (it will use your house main wiring for data, YMMV depending on how your house is wired and distance). Don't understand your problem here. Plex docker (e.g. LSIO one) has separate mappings for Movie, TV, Music etc. Even "merging in Windows" is a matter of creating a folder and mklink -D to the various network share. You totally underestimated the effort required to open your server securely to the Internet. If your ISP allows WAN access then try Nextcloud + LetsEncrypt. If your ISP doesn't allow WAN access then the next best thing is Google Drive. With regards to your VM keyboard issue, the process is: shutdown the VM, wait for it to fully shutdown, edit VM, untick + tick, save, start VM. Next time you try, make sure to take screenshots of every step + any error. Buying off-the-shelf NAS without proper research can be worse. Don't blame lack of research on money.

It would be a good idea to attach diagnostics Tools -> Diagnostics -> attach full zip file in your next post. Your wireless keyboard probably went into power-saving mode which is a common feature with wireless stuff. Your situation with wired keyboard could have been fixed simply by editing your VM and untick the USB device corresponding to the wired keyboard. No need to nuke your VM. If you still have the vdisk of the old VM around, try it (so no need to reinstall Windows). If you don't have the old vdisk then install windows with the wired keyboard, make sure everything boots fine, shut the VM down, edit template to untick the wired keyboard + tick the wireless keyboard, save and start VM again. Your frustration probably stemmed from not asking questions (I'm guessing from your 1 post). Next time you have problems, it's a good idea to ask on here since chances are someone will be able to help. With regards to USB controller, it may not be necessary to buy a PCIe card. Some motherboards have onboard USB controllers that can be passed through. And finally, go watch Unraid tutorials on the SpaceInvader One channel on Youtube.

There are 2 limits. 750 GB / day transfer limit API limit I can't remember the exact number anymore but Google measures how many API call is done every minute and if you exceed it, you will be locked out. I think your ISP probably can only limit your overall transfer and not API call. Using mergerfs (or unionfs) + Team drive allows you to quickly switch to a user if one is locked out (or have multiple users, each for a certain purpose). API call is actually quite hard to exceed (with subtitle app being the common exception) so you may not care but keep that in mind.

Wrong place to ask (you are better off on the Unraid Nvidia support topic).

You probably will get more responses with a separate topic as you are asking about hardware recs instead of discussing whether 10th gen is supported.

It's not a "will" - which implies 100% certainty. If your card is passed through to a VM then it would follow any power scheme set by the driver installed in the VM, which generally should do the power management for you automatically.

This feature request has nothing to do with your problem. Based on your previous post, it's GPU pass-through, which isn't GPU virtualisation. Also, SIO tutorials with regards to pass through are very certainly NOT outdated. While I understand your plight of not being able to get PCIe pass-through to work, I don't think you appreciate the danger of having a "list of supported hardware" when it comes to PCIe pass-through. There are nuances that would be impossible to put in a generic list. For example (just to name some that I know of), Some cards work but only if it isn't initialised at boot Some motherboards don't allow you to change primary display Some motherboards disable onboard graphics if dedicated card is installed Some motherboards (BIOS) + CPU combo just downright don't cooperate with passthrough UEFI boot may or may not initialise display Motherboard BIOS e.g. different BIOS for different vendors may or may not work and there's no way to know in advance without someone actually testing it out Some cards work with quirks if already initialised at boot e.g. reset issue There are workarounds for reset issue but may or may not work Some cards work with special kernel patch e.g. Vega Kernel patch would break other working cards so can't be released with general Unraid release Dumping vbios User cannot dump own vbios and download wrong vbios from TechPowerup Dump vbios incorrectly New hardware / technology / kernel version breaking existing working hardware (or making previously-not-working-hardware work) Plenty of examples with Ryzen BIOS updates Threadripper "dirty patch", PCIe root port patch etc. 10th-gen iGPU can't be passed through but 8th-gen is ok So having a "list of supported hardware" would put the burden and responsibility on LT to provide support for things that would be virtually impossible to support without being physically at the site. A lot to ask for a small team with such cheap product (if you know how much Microsoft and the like charge for that kind of support).

That assumption is correct. No need to recreate stuff stored on the storage devices. You probably are thinking Windows. If Windows installation is corrupted, chances are you will have to reinstall Windows + all the apps like Office. Unraid is different. Using the Windows analogy, the Unraid USB stick is like your motherboard BIOS. A corrupted BIOS means your Windows won't boot up at all but reflashing the BIOS doesn't require you to reinstall Windows.

"If things go wrong" is a very generalised situation. Restoring the usb stick is a very specific action for a specific event i.e. your USB stick is corrupted, which is an independent event from lost data (e.g. docker appdata) so they shouldn't be in the same discussion. The stick only contains Unraid and plugin configs (e.g. what disk to assign to what slot, etc.). For example, it stores WHERE in the storage devices (i.e. your HDD / SSD) to look for docker image (and VM libvirt i.e. xml template) but not the docker nor the "appdata" (referring to the docker appdata, NOT the Unraid configs). A corrupted stick will NOT affect any data that is stored on the storage devices (i.e. your HDD / SSD), including docker image, appdata, VM etc. And conversely, restoring to a new flash drive will NOT, on its own, bring back your docker and VM settings. If your docker / appdata is lost, you would restore that separately from the backup (or as a last resort from the cloud). There is still merit to having a live backup of your boot stick even if you still need a secondary computer to make it bootable. Firstly, storing your flash backup in a share (i.e. the Unraid array) isn't really a good idea because you need the Unraid stick to boot up the array to get the backup, which you can't because your main stick is corrupted and you need to restore to a new stick, which is always a last resort action. Having a live backup stick plugged into the system will preempt stuff like Where is my backup stick? <-- funny but true, try looking for a USB stick you haven't touched since last year Where did I store my backup? Oh no, Internet is down, can't get things back from the cloud Dropbox is down etc. So with a live backup stick, you just unplug from server, plug to your (let's say) laptop, change volume name to UNRAID, run make_bootable.bat, put new stick back on server, turn on server, boot up, license replacement procedure. Done.

Note that there's a catch AFAIK with flash backup. There can only be 1 device mounted with name UNRAID (exactly that name) so your backup stick partition cannot have the same name. However, Unraid would only boot with a partition named UNRAID exactly. Therefore, you would still need to use a secondary computer to rename your backup stick to UNRAID (and run make_bootable etc.) for it to boot.

USB stick only contains config for Unraid (e.g. the array, disk settings etc.) and plugins. Dockers and VM configs are on the storage device (array / cache) so they are not part of the flash backup. There is a CA Backup plugin (can't remember exact name) in the Apps store that you may want to have a look. Backing up straight to a spare USB can be done by setting up a script to periodically sync between the main stick and the backup stick.

I would say you are better off getting the ZFS plugin and run your HDD in ZFS RAIDZ1 instead. More space and no write hole (so lower risks from slow scrub).

It's normal for scrub to be slower than your normal speed. Long scrub time is partly the reason why don't recommend BTRFS RAID-5/6 with HDD. Shameless plug: I just did a relatively long write up about BTRFS RAID-5/6 in my build log so have a read (which among other things explains why long scrub time is probably not something you want).

The "no-no" regarding BTRFS RAID-5 has been outdated for about 2 years (4.17 - Jun 2018). It's kinda funny how some outdated noises can have such reverberating impact. BTRFS RAID-6 has been no-no until 5.5 (Jan 2020) with RAID1C3 implementation so metadata chunks have the same resistance to 2-drive failure as data chunks. Before 5.5, it would be pointless to run BTRFS RAID-6 because a 2-drive failure means irrecoverable lost of some metadata chunks (assuming it's in RAID-1). I have had a few disks dropped offline (not simultaneously) in my BTRFS RAID-5 pool and recovering was basically running scrub. The only outstanding issue that causes it to be marked "unstable" is the write hole problem but then hardware RAID also has write hole problem and nobody calls it "unstable". There are ways to mitigate it and the risk of it happening is rather low to begin with. So no, aint a no-no. 😉

Ditto what itimpi said. You can have multiple cache pools with 6.9.0 (currently beta 25 but IME very stable) and run the SSD "array" as a pool (e.g. btrfs raid 5 for parity). Pro is it's faster than normal array parity, support trim and can have a vdisk larger than a single drive. If you just want to divide your array into SSD vs non-SSD section, it's already do-able by changing your shares settings to include on the SSD or exclude the HDD from the gaming VM share. There's no need for a separate array.

This cracks me up. 🤣 It would be impossible to provide any kind of guarantee that "it would work" because there's no way to know what "modification" was done to the software. If it were a legitimate copy of Unraid then my hunch would be a bad USB stick but then it isn't so...

You should start a new topic with the details instead of adding to this topic, which is based on some outdated tweaks (e.g. turning off Hyper-V). Adding more to this would create the impression (particularly to new users) that it's the way to go with error code 43 when in fact it's the equivalent of bulldozing a wall, based on the outdated assumption that the wall needs to be demolished, when there are a set of known gates to get in and may not require such drastic actions.

There isn't a more recent one because this whole guide is outdated. SpaceInvader One Youtube channel is probably a better starting point.

This guide is outdated.

That should NOT be attempted. Exposing the Unraid GUI to the Internet is asking for troubles since Unraid was never intended for such use. You should set up a VPN (e.g. Wireguard is included via a plugin or use OpenVPN) and use that to access the GUI.

That's normal. The CPU thread is used to load data to and from the GPU and it's a substantial amount of data to load. That's why it's important to ensure you pin the right cores for the F@H docker to prevent lag to the important stuff.

If you use the lsio docker then in the nginx config should have a lot of ".sample" files. Look for nextcloud.subdomain.conf.sample and rename to nextcloud.subdomain.conf and then open it in an editor and follow the instructions. If you aren't sure how to do the config then ask in the letsencrypt support topic.

One thing at a time. Yes you must have port-forwarding for it to work. Once you set up port-forwarding, start the Lets-encrypt docker test protech.my to make sure you arrive at the default NGINX page (e.g. instead of cloudflare error) Then go to nginx config folder and do the .conf file

Try turn on "Bypass single root folder" and "Shared books are in a Calibre library" in the Advanced settings. PS: your questions probably are better asked in the Ubooquity support as they are not specific to the docker.

Disabling proxy will use normal DNS process which has a lag between your update of the A record and when it's effective so perhaps that was why it didn't work for you. Enabling it means it always routes through Cloudflare first (you can run DNS check and you will see Cloudflare IP instead of your actual IP). That means any update to the A record (you might even say it's a "virtual" A record) on Cloudflare would be effective practically immediately. The whole point of using Cloudflare DNS is its proxy capability so your actual IP isn't revealed (e.g. avoid DDOS) so there is really no reason to disable it.