John_M

Did you try searching the forum for the error message you're seeing? Here's one result that might help:

From the link you gave: Presumably, it's lacking a driver.

From the manual:

Posting all those test data doesn't really help because it takes a lot of time and effort to sift through it and it doesn't seem to lead anywhere useful.

It's best not to do that. The thread might prove useful to someone else in the future.

The last line of your syslog snippet seems to be indicating which DIMM is at fault. What does the BIOS event log say? Are you using the very old version of MemTest86 that's included with Unraid? If you go to the MemTest86 website and download the latest free version you can make a stand-alone bootable USB stick (obviously, a different one from your Unraid USB!) which is able to see through error correction. It's a shame the bundled version can't be updated but the licensing doesn't allow it.

Don't do that. Don't do that either. The BIOS setting you're looking for is Power Supply Idle Control. You should find it buried in the extensive AMD CBS submenu. The default setting is either "Low Current Idle" or "auto". You can change it to "Typical Current Idle" and it will prevent the CPU from entering the very lowest power mode from which early first generation Ryzens sometime fail to wake up. However, I don't think this is your problem, for two reasons. Firstly, you don't have a first generation CPU. The BIOS change won't do any harm though. Secondly, your server responds to pings, which I don't think it would do if the CPU was frozen. Your diagnostics don't reveal very much because they cover less than a minute of up-time. But I notice you have a very strange and invalid memory configuration: 3 x 8 GB plus 1 x 16 GB, giving a total of 40 GB. Try running with just a pair of 8 GB DIMMs for a while.

It therefore has to be a different problem because you are not using btrfs RAID. Go to Tools -> Diagnostics and post the resulting zip file.

The only relevant file that I can see is the /boot/config/ident.cfg file. That's where the NTP configuration is stored on the USB flash device. You could try deleting (or renaming) yours and replacing it with the one from the fresh config that you know to work. Maybe the file is corrupt in some way - an illegal character, possibly.

The easiest thing to try is to reboot the server and start the array but not the VM. Let it run for a while then start the VM, noting the time. Let it run for a short time then shut it down. Then grab diagnostics. I'm just trying to establish whether the error messages are produced continuously, or just when the VM is running. I'm not sure why you have to run a script - does the vfio binding mechanism that's built into Unraid not work or are you trying to do something specific?

Do the messages stop when you shut down your Windows 10 VM?

Your syslog is being spammed with this message May 27 11:41:28 Tower kernel: vfio-pci 0000:01:00.0: BAR 1: can't reserve [mem 0x90000000-0x9fffffff 64bit pref] ### [PREVIOUS LINE REPEATED 7223 TIMES] ### which is related to your Nvidia graphics card and the fact that you've bound it to the vfio stub driver for passthrough. I don't know the cause but you could try a web search.

The system was unable to download the plugin installation file from github. There could be a number of reasons for that, but one thing that's often overlooked is that for https (encrypted) connections to work the system clock needs to be reasonably accurate. A wrongly set date could also explain why your licence has appeared to expire. Go to Settings -> Date and Time and make sure the date and timezone are set accurately and get the time set reasonably accurately, too (within 10 minutes should be close enough to start with). If it's old hardware you might need a new lithium cell. Ntp should keep the time accurately in sync in the long term.

Tools -> Diagnostics and attach the resulting zip file.

No, the trial licence gives you the same features as the paid-for Pro licence - the only difference is that it's time-limited. The boot system loads the operating system entirely into memory and it runs from there but configuration changes are written to the USB device and read from there when needed. Also the licence is checked at intervals. So the USB stick needs to have a reliable connection. For the best reliability use a compact (so it's less likely to be disturbed) stick. Choose a branded (Sandisk, Verbatim, Toshiba, Lexar, etc) USB 2 spec device and plug it into a USB 2 socket, if you have one. For this particular purpose USB 3 is not better because the system runs from RAM and so doesn't need the speed advantage, and USB 2 devices are more reliable and run cooler. Maybe you've now fixed the problem by re-seating and re-creating the files but if it continues to be a problem post your diagnostics. Go to Tools -> Diagnostics after experiencing a problem and before rebooting, and attach the resulting zip file.

That's a clever use of the options available to you. I haven't done a lot of testing but I think the ACLs are set up when a second user is given permissions to access a share in the SMB User Access section (ie. when Unix permissions are no longer sufficient). They are simply applied to the top level directory and propagated to its contents. I think the majority of users settle for Public shares because they are the default, they usually "just work" and because Windows networking is already more fraught with difficulties than it needs to be.

From your description, it sounds as though the server isn't able to read the USB boot device reliably. Did you disturb it when you moved the server? Again, from your description, you shut down properly. Shut it down again and re-seat the USB device in its socket.

In the GUI go to Settings -> Users. Add a user to Unraid for each Windows user you have. If you make the names and passwords identical to how they are in Windows, you'll save yourself a lot of grief. In the GUI go to Shares. Create a new user share. In SMB Security Settings make it Private or Secure, depending on whether you want to allow guest read access. In SMB User Access set up for each user whether he has read and/or write access. If you want guest write access, just make it Public instead. Each file/directory is owned by its creator and additional read/write permissions for other users are stored in ACLs.

He does if you've given him permission in the user share's configuration:

It means ACLs are in use, which is how Unraid manages Private and Secure user shares, giving different users specific read/write permissions, which is not possible using basic Unix permissions.

What happens if you disable the bonding and use iperf3 to test eth0 on its own, and eth1 on its own?

Did a search for that Windows error message reveal anything? I see mentions of Windows firewall causing large file transfers to fail. Is your home network defined within Windows as a public or private one?

That's a feature of the closed source Nvidia driver being called every second by the GPU Stats plugin. It's discussed in the support threads for both. The easiest way to get rid of it is to uninstall the latter.

From the online help:

There's the Secure option that might fulfill your requirements. Turn on Help in the GUI for more information on that.