John_M

Unraid support various bonding modes with various benefits. The default bonding mode is mode 1 (active backup), which gives link redundancy (in case a cable gets unplugged, for example) but no throughput improvement. True link aggregation (mode 4 - IEEE 802.3ad) allows two 1 Gb/s ports to be made to work like a virtual single 2 Gb/s port with the advantage that if one link fails the other can continue at 1 Gb/s. If your client PCs also have a pair of 1 Gb/s ports, bonded the same way, then you can achieve a maximum theoretical throughput of 2 Gb/s. The disadvantage is that you need a managed switch that supports link aggregation. Mode 6 (balance-alb) offers adaptive load balancing and is the one I use. The advantage is that you can use inexpensive unmanaged switches, while still getting link redundancy, and improved throughput if more than one client is used. By bonding two 1 Gb/s ports multiple clients can share 2 Gb/s of throughput, which is an improvement over the 1 Gb/s shared between them if you don't use bonding, but any given client can only make use of one of the links at any one time. If you go to Settings -> Network Settings and turn on help you'll see all available options and a description of each in the Unraid WebGUI.

Actually, the better solution is to look for a "Power supply idle mode" setting in the BIOS* and set it to "Typical current idle" rather than the default "Auto". That still allows the CPU to enter C states but doesn't allow the power to drop so low that it can't wake up again. The issue only affects 1000-series processors. *Typically under Advanced -> AMD CBS -> Zen Common Options

Don't worry. It's good stuff!

Since split level takes precedence over allocation method, what happens when Disk 1 is (almost) full? Since you have Minimum free space set to zero, will the allocation ever move on to Disk 2 or will all subsequent writes fail due to lack of space? I don't use split levels myself and I tend to prefer the fill-up allocation method over high water.

I already wrote one for AFP some time ago and if anyone wants to use SMB there's a guide here: https://wiki.unraid.net/UnRAID_6/Configuring_Apple_Time_Machine and it's stickied here:

You'll need to use SMB instead of AFP and turn on Enable enhanced macOS interoperability. It should be fine for modern Macs running recent versions of macOS (Sierra and later). Not for old Macs running old versions of OS X though. It affects me but I'm not complaining as I knew it was coming and I've switched over to using dedicated USB-connected 2.5-inch hard disks for Time Machine purposes. That has improved Time Machine reliability and also freed up server space.

That isn't how parity works, I'm afraid. Go to Tools -> Diagnostics and post the resulting zip file for advice on how best to proceed.

See this thread: I think there was also some issue with Unraid 6.7 that made it happen more often. I haven't seen it since upgrading to 6.8.0-rc1. I use bonding mode 6 because it works with regular cheap unmanaged switches, though it isn't as effective as mode 4, i.e. a given client can only get a maximum of a 1 Gb/s connection, though two clients can each get 1 Gb/s simultaneously and it has the benefits of redundancy.

I find it easier to tell the difference with the light theme. That's what I normally use but I switched to dark temporarily and found that it's difficult to see the difference between bold text and regular.

To get the "More" tab you have to have the Dynamix System Information plugin installed. This isn't a feature of 6.8.0 as the plugin works with older versions too.

That was quite a tricky one to find. It's on the Settings -> Notification Settings page. Set Plugins update notification to Never check.

Since all registered users and the "nobody" user are all members of the group "users" there should never be any need for read, write or execute permission for "other". In other words, 770 is the maximum permission that should be necessary for any directory inside a share.

Is it necessarily a problem? General Unraid permissions (mode 777) are ridiculously lax. Even the permissions on the folders indicated are unnecessarily generous. I'd like to see a general tightening up of permissions in the interests of security. The changes in the recent Unraid 6.8.0-rc1 release are a step in the right direction and I hope there are more to come.

I find that very occasionally some settings like that get "lost" or don't "stick" when changed. When you run a SMART self-test the spin-down delay for that disk gets set temporarily to "never" and sometimes I've noticed it doesn't get restored properly afterwards. The solution is to toggle it manually.

As I said, I had never heard of DOCP. I know eXtreme Memory Profile was developed by Intel as an extension to the JEDEC SPD specification, but all the AMD boards I've ever used call it XMP, not DOCP. Anyway, in an attempt to find out what it stands for (Direct Over Clock Profile - from Asus) I found this: https://forums.tomshardware.com/threads/what-does-xmp-docp-eocp-mean.2789837/

It would be useful if the original post could be updated to insert the missing linefeeds.

The I211 NIC works fine with Unraid.

Is DOCP an Asus-specific thing? Can you simply set an XMP profile? Is that even an option? I see your RAM is on the QVL for Pinnacle Ridge processors so it should work fine as long as you don't try to push it. I use mostly Gigabyte and ASRock motherboards at the moment but I do have an Asus Prime X470 Pro, which I don't think is hugely different from yours, with a 2700X. In each case I make sure the RAM is qualified when I order it and I simply set the XMP option, without trying to adjust any of the timings. The only problem I've had was with a clearly faulty DIMM, which failed Memtest very quickly and the set was replaced without question.

Is the 100 Mb/s one always eth1? Are the two NICs the same make/model/version? What happens if you change bonding mode to 1 (the default) and preferably connect both ports to a simple unmanaged switch?

Hence my advice.

Did you try trurl's suggestion, above? Also, if it exists, delete the config/network-rules.cfg file from the flash to reset networking completely.

Here's what I see. My hardware does have AMD-V capability and I can enable or disable VMs at will. Did you perhaps migrate your server from different hardware that supported virtualisation, allowing you to turn it on, but now not turn it off?

In that case you'll want to turn off the VM service in Settings -> VMs to stop it trying to start up.

I don't see anything out of the ordinary in your syslog (though it obviously was grabbed after the reboot so it won't show what led to the crash) but you probably need to check the virtualisation settings in your BIOS if you're planning to run VMs: Oct 17 09:28:13 BasinNAS root: Starting virtlockd... Oct 17 09:28:13 BasinNAS root: Starting virtlogd... Oct 17 09:28:13 BasinNAS root: Starting libvirtd... Oct 17 09:28:13 BasinNAS kernel: kvm: disabled by bios Oct 17 09:28:13 BasinNAS root: modprobe: ERROR: could not insert 'kvm_intel': Operation not supported I don't use a domain myself and have little experience of them but I suppose this is the line in the syslog that shows the attempt to join: Oct 17 09:26:47 BasinNAS emhttpd: req (1): DOMAIN=BASINDESIGN.local&DOMAIN_SHORT=BASINDESIGN&DOMAIN_LOGIN=UNRAID&DOMAIN_PASSWD=&cmdJoinDomain=Join&csrf_token=**************** So it seems to be trying to join but is it being rejected by the domain controller? You maybe need to check the domain controller's logs.

First of all, I see a Python process that's segfaulting: Aug 20 10:06:25 Dataserver2 kernel: python[31677]: segfault at 6e6f68747988 ip 0000147723a127e8 sp 000014771b8cf098 error 6 in ld-musl-x86_64.so.1[147723a05000+46000] It seems to happen after autofan adjusts your sever fan speeds, so maybe it's related. Secondly, there's this: Aug 21 16:33:48 Dataserver2 nginx: 2019/08/21 16:33:48 [error] 4260#4260: *847010 user "root": password mismatch, client: 167.220.149.78, server: , request: "GET /Main HTTP/1.1", host: "turtlerr.com" Do you recognise the 167.220.149.78 address? You could be being attacked from outside if you have ports open to the Internet. Thirdly, more worrying attempts to connect, trying different user names: Aug 26 07:22:48 Dataserver2 nginx: 2019/08/26 07:22:48 [error] 4260#4260: *2792365 user "admin" was not found in "/etc/nginx/htpasswd", client: 23.225.205.151, server: , request: "GET /Main HTTP/1.1", host: "99.61.88.74", referrer: "http://99.61.88.74/" Aug 26 07:22:48 Dataserver2 nginx: 2019/08/26 07:22:48 [error] 4260#4260: *2792371 user "super" was not found in "/etc/nginx/htpasswd", client: 23.225.205.151, server: , request: "GET /Main HTTP/1.1", host: "99.61.88.74", referrer: "http://99.61.88.74/" A different IP address. Do you recognise it? These are repeated over and over, testing a variety of different usernames. This goes on for several days. You should close all ports and use a VPN instead. Fourthly, this: Oct 7 12:48:48 Dataserver2 kernel: BUG: unable to handle kernel paging request at 0000000000006111 Oct 7 12:48:48 Dataserver2 kernel: PGD 0 P4D 0 Oct 7 12:48:48 Dataserver2 kernel: Oops: 0000 [#1] SMP PTI Oct 7 12:48:48 Dataserver2 kernel: CPU: 21 PID: 11162 Comm: chown Tainted: P O 4.19.56-Unraid #1 Oct 7 12:48:48 Dataserver2 kernel: Hardware name: Supermicro X9SRE/X9SRE-3F/X9SRi/X9SRi-3F/X9SRE/X9SRE-3F/X9SRi/X9SRi-3F, BIOS 3.3 05/29/2018 A bug, a kernel oops and a call trace. It looks as though it tries to shut down when commanded to but doesn't make it: Oct 7 13:10:51 Dataserver2 shutdown[20380]: shutting down for system reboot Probably the system is too messed up by that time. My advice is to get it secured behind a firewall and update the OS to version 6.8.0-rc1, which has a much newer kernel. Update your plugins and apps too. I understand that there have been some dockerhub outages recently, affecting certain regions of the world.