testdasi

vbios is never a "required" thing. It's a "fix" thing i.e. if you have problems passing through a GPU (regardless of brand), that is a fix that you can attempt. It is particularly relevant to passing through a primary GPU. In fact, my general recommendation is, where possible, dump your own vbios regardless. It can only help with stability.

I think I found a bug with the rclone-beta plugin. It is now looking for the config in the rclone plugin folder instead rclone-beta like it previously did. Sounds to me like a copy-paste bug. Switched to rclone plugin and everything works, but then I don't do exotic stuff, just plain old empty mounts so I reckon I have never had the need for the latest beta build anyway.

I posted this on another topic also about being stuck at Tiano core. With cards that don't like being passed through, the following seem to help: Boot Unraid in legacy mode - I purposely disabled UEFI when building my USB stick to ensure if it boots, it 100% boots in legacy mode. Set primary GPU as something other than the to-be-passed-through card in the motherboard BIOS Use Q35 machine type (I recommend starting a new template from scratch AND use Unraid 6.8, save you the trouble of needing the root port patch) Dump your own vbios and use it

vfio stubbing shouldn't cause your server to fail to boot unless you have stubbed something critical. Perhaps, you may have some other inherent issues. Anyway, start with the simplest "fix". Are you booting Unraid in legacy mode (i.e. NOT UEFI)? That simple step solves a lot of my PCIe pass-through issues so I would suggest starting from there.

@jonp: by "select Q35 for Windows-based VMs", you meant as part of Unraid pre-built VM templates? As far as I know, the VM xml doesn't have any tag that says "expected OS" or something like that. Picking PC type = Q35 is a generic qemu option so it would take effort on Unraid dev part to disallow it. I sincerely hope you are not talking about disallowing Q35 as a blanket ban because that would be a catastrophic mistake. Putting effort into banning something that causes no harm to the majority of users while possibly helps some (even if a niche group) is nuts. On a related note, I believe qemu 4.1 (Unraid 6.8.0-rc) no longer requires the patch. I removed the custom xml tags and my PCIe runs at full x16 speed as far as I can tell.

Guys, I don't think you need Waseh to update the script to get latest version of rclone. Having a look at the plugin code, I believe he sets it up to download whatever the latest version is at the time (of boot). So a restart will get you the latest version. For example, below is my current version: :~# rclone --version rclone v1.49.0-007-g16e7da2c-beta And below is from rclone beta website (https://beta.rclone.org/) v1.49.0-007-g16e7da2c-beta—29/08/2019, 11:08:23 v1.49.0-008-ge2b5ed6c-beta—02/09/2019, 06:04:57 My last reboot happened to be on 01 Sep 2019, which is why my rclone version is v1.49.0-007 (latest on that day).

CA User Script schedule has an option to "Run at first array start". Schedule the script with that and it should be fine. 4GB is more than enough for most users so it's a good starting point. If you start getting issues then increase it but it's unlikely. It should be enough for at least 5 1080p streams (a 4k stream is about 4x1080p streams).

Sorry but I disagree. LT has always been so often too nice and bowed down to pressure from the minority that happens to scream really loudly about niche issues. e.g. new GUI too big / small and certain people refused to use their browsers' native zoom functionality and demanded very loudly that LT changed everything back to the way they were familiar with - and guess what, LT spent time and resource responding to these GUI supremacists while ignoring the fact that Gigabyte X399 users (e.g. me) have severe lags that to-date still have not been resolved. So it's rather refreshing to hear LT dev(s) get the balls to respond to loudmouth screamers in a different way. Donald Trump and Boris Johnson come to power because people are too nice to scream back at them.

Just our of curiosity, other than "I don't trust [Insert Cloud Provider]" and "I'm Linus Sebastian / Marques Brownlee", is there any particular reasons that warrant 100TB+ storage server?

Yes, Lightroom has that feature to allow you to edit stuff locally with the RAW on the network. I have never used that functionality in any serious manner though. Performance is better than editing RAW after the initial ingress wait. That's expected though since you are essentially editing a simplified version of your RAW files. If I were you, I would set up a VM on the 1700 and editing via RDP. Would be a waste of the 1700 otherwise. Of course if you use the server for other purposes then you can use the Lightroom feature you mentioned. My workflow is generally have my files in "local" NVMe SSD for things that I still need to edit. Once done, I move everything to the NAS. But then my NAS and workstation is the same machine so it's different.

Google built-in stuff to Google Drive then rclone it down to my server.

Unraid does not require a GPU to boot but your motherboard may. The only way to know is to try booting without a GPU. In terms of performance, it depends on how you define "performance". I don't use Capture One but am very familiar with Lightroom. From my experience Core count matters with parallel-able tasks e.g. exporting, generating preview. There's diminishing return but my 24-core performance is still better than 8-core performance. Base clock matters with snappiness e.g. moving between modules > 8GB of RAM only matters if you edit very large files e.g. 100Mpx kinda thing SSD matters for db and previews. Matters even more if you can separate the image files from the db and previews. NVMe barely makes any dent GPU-acceleration matters when it works (but only to parallel-able tasks). Unfortunately, my 1070 has issues (e.g. blank screens, blank previews etc.) LAN speed matters if working remotely but I have found Wifi-level speed sufficient. Why would Internet speed matter? I do RDP to my workstation VM and found it usable. However, I do use my VM directly when dealing with serious works. You probably shouldn't hijack someone else's topic. Better to start your own topic to ask your own questions to minimise confusion.

Oh dear, don't use Syncthing directly on the mount. It's a rather long explanation as to why it doesn't work but just trust me, it won't work.

The latter i.e. it maxes out your 512MB limit.

The log you quoted is when the FCP plugin telling you that there WAS an OOM error on your server. It's not the timestamp of when the error happened. You had OOM errors on these time stamps: Aug 12 09:44:31 Aug 12 09:44:31 Aug 12 13:18:52 Aug 12 13:21:22 Aug 12 13:24:13 Aug 12 13:27:43 Aug 12 13:33:33 Aug 12 13:39:09 Aug 12 13:46:12 Aug 12 13:53:01 Aug 12 14:01:44 Aug 12 14:10:04 Aug 12 14:18:17 Aug 12 14:28:35 Aug 12 14:39:17 Aug 12 14:52:36 It looks to be all by docker a42f60d82242a9af576f67954002ad97b0c1f2e70e603a58ac3e7cb02cfb2e83 Go to Docker tab, click the toggle next to "BASIC VIEW" to enable "ADVANCED VIEW". Under each docker you will see Container ID. Container ID only has the 1st 12 characters but it should be enough for you to match it to the problem ID above.

I understand your point but I can reliably reproduce this with my VPN (PIA) by simply switching to a non-port-forwarding server. I would lose access to the interface within 10 secs or so after docker start but I can tell the docker is still running based on network stats. Maybe something peculiar about my network / ISP.

Assuming you didn't change any networking settings from default, that sounds like your VPN server doesn't support port-forwarding.

Unassigned Device (i.e. this plugin) is the right tool. Install it and mount your volume. It should show up under /mnt/disks Just in case: make sure you don't include your existing drive in the array / cache pool or there's a risk it will be erased. What the statement means is that if you format a disk as (for example) xfs, you can include it in the array without Unraid asking you to reformat the disk (and thus keep your existing data on the disk). You will still have to rebuild parity.

You are overthinking it a bit. 😅 Your CPU is not a chiplet design so it's much simpler Keep core 0 free for Unraid Preferably also keep the HT sister of core 0 free but if you really can't avoid it, it's not that big of a deal as long as it doesn't get loaded 100% all the time Isolate CPU cores for VM - which you have already done Use 1 logical core (i.e. thread) for the emulator per VM From my experience, using more than 1 thread/VM for the emulator does absolutely nothing You can use the HT sister of core 0 for the emulator but should not for best performance That's about it really.

My Samsung 970 Evo and PM983 work.

Does this support encoding to H.265 aka HEVC?

You mean changing the "Cache" box to Yes in the share settings in the Unraid GUI? That should be safe as long as your mount scripts are all /mnt/user.

Sorry but your question is very ambiguous. What kind of issue? What kind of "use"?

If you need to do a "reset" without having to restart, you can see the PID in Tools -> Processes and then in SSH just kill all the rclone and unionfs processes using the kill command (PID separated by space) e.g. kill 12345 23456 34567 I actually have never had the mount drop on me. Even when I unplug the router, the mount just reconnects itself automatically once replug (without the need to run the mount script). So your issue sounds more like rclone mount crashing / got killed / kicked. That is usually due to insufficient memory. That sounds like you "touch mountcheck" the unionfs mount + the rclone mount.

That usually means the folder wasn't created for some reasons and/or your rclone mount command uses a different path. There is a mkdir line in the script e.g.: mkdir -p /mnt/user/mount_rclone/google_vfs Do you find an mkdir line in your mount script? Instead of doing screenshot of the scripts, it's better if you copy-paste your script into a post (remember to use the forum's code functionality - the button that looks like </> so it's easier to check).