John_M

The temperature that the built-in sensors measure is of the silicon die itself, below the metal heat spreader. The temperature of the bulk of the heatsink mounted on top will be substantially lower than that. In addition to the sensors built into the CPU there are various other temperature sensors on the motherboard, such as underneath the CPU socket. The question is, which of these sensors is being read and used by the OS to produce the temperature display in the Dashboard? I don't know what's used by default but if you open up a terminal session and type sensors you should get some indication of which sensors (and their current values) can be read. There's a plugin called Dynamix System Temperature that you can install, which provides a simple means of scanning for temperature/voltage/fan speed sensors and loading the appropriate drivers, if available. It might be worth giving it a try.

How are you measuring its temperature? The 95 degC shown in your screenshot is clearly wrong. Have you changed the Power Supply Idle Control option in the BIOS to Typical Current Idle? If your CPU doesn't fail the kill-ryzen.sh test then it doesn't have the segmentation fault bug. What is its date code?

You could try downgrading - version 6.6.7 might be worth a try and it's still available on the download page. You might want to run MemTest from the boot menu for 24 hours or so to check the RAM, since bad memory could cause pointers to get messed up. You can easily try running without plugins by booting into Safe mode.

You're hitting a kernel bug. I would recommend upgrading to Unraid 6.8.0-rc5, which has a very different kernel. You are already running the newest "stable" release but it is known to have a few problems. If you don't like the idea of running a release candidate then you'll have to wait for 6.8.0 final to be released. Don't forget to switch off the "mirror syslog to flash" option now it has served its purpose.

A late call, but I think BIOS 4207 is the best one for you for the time being. It has AGESA 1.0.0.6 and is the latest that supports only 1st and 2nd Gen, with no support for 3rd Gen. If you want to upgrade to 3rd Gen later you'll have to wait until the recently announced AGESA 1.0.0.4 (yes, the numbering system is awful - it jumped backwards and is counting upwards again) is available for your board. The latest BIOS for your board at the moment is 5220 with AGESA 1.0.0.3ABBA, which supports Gen 3 (except for the 3950X) but still has broken PCIe passthrough. Keep an eye on this page: https://www.asus.com/us/Motherboards/ROG-STRIX-X370-F-GAMING/HelpDesk_BIOS/

Compared with your 6.2.4 the latest stable version (6.7.2) contains a lot of security updates, some new features, some cosmetic tweaks and a couple of nasty bugs. I wouldn't recommend upgrading to 6.7.x but instead wait for 6.8, which is currently at the release candidate stage and contains fixes for those bugs. If you really want to upgrade now, then 6.6.7 is a good choice for the time being. Just a guess, but your Plex problem might be a double NAT issue. LTE operators typically don't give their customers a public IP address but hand out 10.x.y.z style addresses and use NAT to hide everyone behind a much smaller pool of public addresses. If your router is then also using NAT for your LAN it can be difficult for hosts outside your LAN to see your Plex server.

How much RAM do you have and how much are you allocating to your VM? Post your full diagnostics as a syslog snippet is not useful.

Static IP addresses are difficult to manage and deploy as it's easy to issue duplicates, get default gateways wrong and make typos when entering netmasks. A much better solution is to make use of the property of a DHCP server to allocate a specific IP address in response to a request from a particular MAC address. The result is functionally equivalent to having a manually allocated static IP address with the benefit that the configuration and management are all done in one place, making duplicates much less likely.

Yes, yes and yes. Also yes to the question in the title. I'm not trying to do anything particularly clever with networking though. The IP address of Unraid is allocated by DHCP, as is the VM's IP address. Are you doing something different? Static IP addresses, perhaps?

mount and umount need to be run as the root user, so on your Ubuntu client you'll need to prefix them with sudo (and enter your password when prompted). So using my share M_Temp from the screenshot as an example, you would use something like sudo mkdir /mnt/Shared_Media sudo mount -t nfs tower:/mnt/user/M_Temp /mnt/Shared_Media and you would access the share via the local mount point /mnt/Shared_Media

You only need it for private shares. If you set the Security option to Private a Rule box appears into which you need to enter the code. Public shares are easier. I'd experiment with those first. On the client you mount an NFS share using the mount command like this: mount -t nfs tower:/mnt/user/name-of-share /mnt/mount-point which is similar to how you would mount an SMB share. Note that you have to specify the full path to the mount (i.e. tower:/name-of-share wouldn't work) and /mnt/mount-point must already exist on the client. To unmount the share you use either umount tower:/mnt/user/name-of-share or umount /mnt/mount-point This information is summarised here: https://linuxize.com/post/how-to-mount-an-nfs-share-in-linux/

Most Unraid users run headless and don't really care about screen blanking. Those who have a monitor attached just press a key and the screen comes to life. Good luck with your search.

The next thing to test is the USB stick itself. Shutdown your server and plug your USB stick into a PC and check/repair the file system on it. With Windows you can right click and choose Properties, then Tools and check/repair the device. With macOS you can use the Disk Utility.

What are you comparing? 4 SSDs in btrfs RAID1 vs 4 SSDs in btrfs RAID 10? I wouldn't expect there to be a huge difference because btrfs is intelligent. RAID 10 guarantees that block n is mirrored across two devices and that block n + 1 is mirrored across two different devices. RAID 1 simply guarantees that each block is mirrored across two devices, but when it has four devices to play with it can be quite creative. Though not guaranteed, there's little reason for adjacent blocks not to be written to different devices where possible, so RAID 10-like performance is not unexpected. You can even have configurations that just wouldn't work with conventional RAID, such as a five-device RAID 10, and they don't even all have to be the same capacity!

For public shares, just enable NFS export, like you have for SMB: For private shares you need to provide an access rule. Here's the one that works for me: *(sec=sys,rw,insecure,anongid=100,anonuid=99,all_squash)

Have you tried any of the suggestions from here: https://unix.stackexchange.com/questions/8056/disable-screen-blanking-on-text-console ? Do any of them work? Maybe some variation of the setterm command? EDIT: More suggestions here: https://www.cyberciti.biz/tips/linux-disable-screen-blanking-screen-going-blank.html

The files beginning with a dot were placed there by a computer running macOS. They are harmless. The lack of a logs folder suggests the flash device is corrupt.

The Dell PERC H310 can be got second hand (pulled from servers) on Ebay at very reasonable prices. That would give you eight ports and it would fit in a x8 PCIe slot. The only downside is that you'd need to cross-flash it with LSI IT firmware but there are instructions and downloads to help you on this forum.

That would be a feature request for Plex, wouldn't it? But isn't Plex server meant to be pretty agnostic about its storage? I'm not sure how this would work or what the advantage would be as TV episode streaming is well within the capability of even the slowest mechanical disk. If you were going to pre-load material to aid "scrubbing" you would need to pre-load it into the playback client.

Marvell-based disk controllers might work well enough with Windows but are especially troublesome with Linux.

That was from the syslog.

Correcting parity checks are the default (wrongly, IMO) so unless you unchecked the "Write corrections to parity" box it was. Your diagnostics, assuming you haven't rebooted since starting the check, would confirm. This is the third time of asking for them. Go to Tools -> Diagnostics and attach the resulting zip file to your next post.

You only included the SMART report from one disk. It is failing and needs to be replaced. I don't know the state of your other disks. Post your full diagnostics.

You don't need to do "various workarounds". The Power Supply Idle Control one is the most effective.

You posted no diagnostics or even mentioned which version of Unraid you're using. However, there is a known issue with the 6.7 releases that is fixed in the 6.8.0-rc series. You might like to consider upgrading.