John_M

On the Shares page of the GUI you'll see two columns, labelled SMB and NFS. For that particular user share (backups) it is behaving as though it is set to Public for NFS sharing and Private for SMB sharing. If that's the case you need to change the SMB sharing to Public.

Is the main GUI page still accessible? If so, go to Tools -> Diagnostics and attach the resulting zip file to your next post. I don't use Windows much or Edge at all. Is it trying to protect you from the threat it feels is posed by the unencrypted connection? Does clicking the "! Not Secure" message give you the opportunity to accept the risk and continue? There are other ways of accessing the Unraid terminal. A popular one for Windows is the free utility called PuTTY. That creates an encrypted connection of its own using ssh, without needing you to use a secure web connection.

Don't do both. Re-enable the Global C States. See above. The kernel panic is not caused by the CPU failing to wake up from the C6 state. If that happens the sever just freezes, but the Power Supply Idle Control setting fixes that. As mentioned above (twice), the panic is likely related to docker networking.

It's the Power Supply Idle Control setting. You'll find it under the extensive AMD CBS section of the BIOS. The default setting is Low Current Idle (or maybe Auto). Change it to Typical Currrent Idle and leave the C states options at their default values. However, this is only effective against freezes when idle, not re-boots.

Yes. Yes. Make sure you format it btrfs as that will make it easier to add a second device to the pool later.

What's the device in question? Other people might have them too so would be useful to know, in case it does have buggy firmware.

The entry in /etc/exports looks correct for a public share. UID 99 is the user "nobody" and GID 100 is the group "users". Is the fsid value of 100 unique amongst the entries in /etc/exports? Your problem, I would say, lies elsewhere but I can't tell where from the limited amount of information you've provided. Check both server and client syslogs for errors when the problem happens.

You could run rsync on each of your shares. If you have several you could write a script based on rsync. You could use the User Scripts plugin to schedule the script. How often you run it depends on how often your file system changes and how tightly you want the backup synced to the main sever.

There are no Marvell controllers on that motherboard. Six of the SATA ports are provided by the X470 (ASMedia IP licensed by AMD) and two are provided by a discrete ASMedia chip, with no port multipliers. ASMedia controllers are generally reliable. I notice you've had two different disks dropped by the same port. Were they connected using the same SATA cable, by any chance? Have you tried replacing that cable?

It is, but you have to set your timezone.

Could it be a Windows driver issue? Are you using a driver that Windows found for you or are you using one that Mellanox provided?

Pending sectors are ones that have failed a read operation and are waiting to be processed (hence, "pending"). Even if subsequent reads are successful, their pending status can only be cleared by a write operation, when the new content is either successfully written to the existing sectors (decrementing the pending sector count) or reallocated to spare sectors (decrementing the pending sector count and incrementing the reallocated sector count). A non-correcting parity check (there's no such thing as a non-correcting parity sync) is, by definition, read-only so there's no opportunity to deal with them there. If Unraid detects a read error it will reconstruct the missing data from parity and the remaining data disks and attempt to write it back to the disk that showed the error. If Unraid detects a write error the offending disk is disabled and its contents emulated, using parity and the remaining data disks. Pending sectors may or may not be readable and that uncertainty is a problem. As mentioned, the ability to emulate disabled disks relies on the ability to read all the remaining disks so it's never a good thing to have a disk with pending sectors in your array. I suspect you disturbed something while cleaning out the dust. If you haven't already rebooted, your diagnostics will shed some light. I think the result of the extended SMART test is reassuring but I would want to replace first one of the disks with a spare and then the other, if only to get rid of the pending sectors. After replacing the first disk I'd run a utility that writes then reads every sector, such as badblocks or preclear, and if the disk turns out to be good, I'd use it as the replacement for the second disk. Then run the same utility on the second disk. A few reallocated sectors is not necessarily a bad thing, as long as the number doesn't keep increasing.

According to this man page, md stands for "multiple device".

Why? Diagnostics provide a lot of troubleshooting information. If you're able to provide them you should always do so when asking for help.

That was the first opportunity to see Disk 2's SMART data. It's not a happy disk. It has a lot of reallocated sectors and a lot of pending sectors. You need to replace it. From your original post you said you were trying to add it to your existing array so it's unlikely to contain any useful data. That's just as well because your Parity disk is not in a good state either. I'd replace that, too. Fortunately, your Disk 1 looks healthy.

The disk looks fine. Replace the SATA cable. The SMART extended self-test checks the disk surface and heads. That isn't where UDMA CRC errors occur. They happen in the SATA connection between the controller and the drive electronics and can be caused by a bad controller, bad drive electronics or bad cable/connections. Most of the time the culprit is the cable, which is fine because it's the cheapest and easiest component to replace. While you're there, make sure the power cable is firmly seated too.

There is still no SMART report - the disk dropped offline before you captured the diagnostics. So I can't tell. Have you checked the power to the disk? Are you sure? Incoming connections are still being made: May 22 12:54:19 Tower vsftpd[21347]: connect from 167.248.133.53 (167.248.133.53) ... May 22 16:02:41 Tower vsftpd[1916]: connect from 104.206.128.22 (104.206.128.22)

Could this be a power problem? May 22 10:47:43 Odin kernel: sd 1:0:4:0: Power-on or device reset occurred It might be worth checking the power cable and any splitters.

It definitely is ftp. There's a clue in the log entry. If you don't need ftp you should disable it and definitely don't forward a port on your router. For more information see here.

It will be limited by the slower of the virtual network connection and the read speed of the disk.

I don't see anything out of the ordinary in your diagnostics, but they only cover a short period.

It's a connection problem: May 22 03:02:18 Tower kernel: ata2: COMRESET failed (errno=-16) May 22 03:02:18 Tower kernel: ata2: hard resetting link The SATA link is reset repeatedly, reduced in speed and eventually dropped. Did you replace the cable? Since Disk 2 is offline there's no SMART report for it in your diagnostics. Unrelated, there's a huge amount of this in your log: May 22 03:02:34 Tower vsftpd[30644]: connect from 58.222.191.157 (58.222.191.157) May 22 03:02:36 Tower vsftpd[30652]: connect from 58.222.191.157 (58.222.191.157) Unless you recognise the IP address as friendly, someone in China is trying to hack you.

In the BIOS, have you set the "Power Supply Idle Control" option to "Typical Current Idle" instead of the default "Low Current Idle"? It can be difficult to find. One route is via the extensive AMD CBS menu. This will prevent the CPU from entering the very lowest power level when idle, a state from which some 1000-series Ryzens are unable to return.

It looks as though it has dropped off-line. Post your diagnostics: Tools -> Diagnostics and attach the zip file to your next post.

Yes, it seems to. I just refreshed the page of a disk that was being read a few times and attribute 242 (Total LBAs read) increased each time. What log entry do you mean?