itimpi

The memtest provided with Unraid will only work if booting in legacy mode. if you want a version that will work when booting in UEFI mode then you can download one from memtest86.com

I think that it is probably quite normal to get that once during the startup sequence, but the system later contacts the NTP server to synchronize time.

You should set a NTP server under Settings->Date and Time. You can Google for suitable public NTP servers.

This is a regression where several fields in the settings are not correctly displaying the current settings. I have fixed for release that is forthcoming shortly. It was a caused by me making a global edit that somehow missed some fields and I did not pick that up. You will find that the values you set ARE being saved when you hit Apply if you examine the file parity.check.tuning.cfg in the plugins folder on the flash drive.

Adding a pre-cleared drive causes NO change to parity so it is added in seconds. After adding it you need to format it but that only takes a few minutes.

Putting the disk back will cause it to be rebuilt to match the emulated drive. That is fine. You could also try running an extended SMART test on the drive before adding it back.

https://unraid-dl.sfo2.cdn.digitaloceanspaces.com/next/unRAIDServer-6.10.0-rc4-x86_64.zip

If you can still read your flash drive I would make sure you have a local copy of the config folder. One thing I know is NOT currently backed up by MyServers is any passwords so you would have to redo these after restoring from the MyServers backup

Rather than perusing the logs you might want to look at the parity.check.tuning.progress.save file on the flash drive. This should contain an entry for each pause or resume. I am currently overhauling the logging messages at each level to make sure you get told about all pause and resume actions even at the Basic logging level. That should give far less verbose output while still conveying the key information.

Simply that USB2 seems to boot more reliably than USB3 so is preferred if available.

If a pause happens this should definitely show in the GUI with '(Paused)' appended to the operation in the status line. Note that this text is done at the core UnraId level and is not added by the plugin so happens even when the plugin is not installed

This is what I mentioned previously. I only intended that message (which is informative and not an error) to happen if the Testing level of logging was actIve, but in the release made yesterday it is happening at all log levels.

That means Unraid thinks the reboot was not actually clean You might find this section of the online documentation that can be accessed via the Manual link at the bottom of the GUI to be of use?

That is a standard warning message and can normally be ignored as mentioned here in the online documentation that can be accessed via the Manual link at the bottom of the GUI

It is a known issue that if you are running the check in increments then the built in Unraid notification gets the time and speed wrong as it assumes the last increment did the whole check. However the notification from Parity Check Tuning should give the correct answer and the parity History file should be patched to reflect the correct values as well. If the plugin is also giving the wrong values then please mention this as then I then need to ask for some diagnostic information to work out why. In particular I am would initially be interested in the 'parity.check.tuning.progress.save' file from the plugins folder on the flash.

Actually your screen shot suggests that the drive IS being emulated - just that it is flagged as unmountable. Handling of unmountable drives is covered here in the online documentations accessible via the ‘Manual’ link at the bottom of the GUI.

The only way ‘root’ could access your shares is if they are set to be ‘public’ as in that case you end up actually connecting as a guest so the username is irrelevant. The ‘root’ user can not access shares set with any sort of security.

Use the ‘diagnostics’ command which writes them to the logs folder on the flash drive.

It is not actually an error It is an information message that was only intended to be output when logging level is set to Testing

That looks benign - I probably have just used the wrong level of logging on the message that gives the PHP level of error reporting and that message should be set to only occur at the “testing’ log level. I will get it rectified. I have just noticed that the setting for reporting notifications on temperature related issues is not being displayed correctly in the settings so a fix for that needs issuing.

Do you have an ‘extras’ folder on the flash drive? Another thing that Safe Mode does is suppress adding any packages from that folder if you happen to have it.

RaM speed being set too low is unlikely to be a problem. What is more frequent is that users try to run the RAM at the max speed quoted for the RAM not realising that the motherboard + CPU combination may have a much lower maximum speed they can run stably.

Did not spot something obviously wrong in the SMART report, although you might want to consider running an extended SMART test on it. if you think the drive is OK then the process for getting it back into the array is documented here in the online documentations accessible via the ‘Manual’ link at the bottom of the GUI.

The issues with the Parity Problems assistant is fixed in the version of the Parity Check Tuning plugin I am currently testing. A silly mistake made in the last update. As far as I know there is no way to identify which drive causes a parity error, or the files it might affect.

According to the syslog the docker image is corrupt: Mar 20 08:40:44 MAHomeLab kernel: BTRFS critical (device loop3): corrupt leaf: root=1 block=47251456 slot=16, invalid root generation, have 882824 expect (0, 882323] Mar 20 08:40:44 MAHomeLab kernel: BTRFS error (device loop3): block=47251456 read time tree block corruption detected Mar 20 08:40:44 MAHomeLab kernel: BTRFS critical (device loop3): corrupt leaf: root=1 block=47251456 slot=16, invalid root generation, have 882824 expect (0, 882323] Mar 20 08:40:44 MAHomeLab kernel: BTRFS error (device loop3): block=47251456 read time tree block corruption detected Mar 20 08:40:44 MAHomeLab kernel: BTRFS: error (device loop3) in btrfs_recover_log_trees:6401: errno=-5 IO failure (Couldn't read tree log root.) Mar 20 08:40:44 MAHomeLab kernel: BTRFS: error (device loop3) in btrfs_replay_log:2423: errno=-5 IO failure (Failed to recover log tree) Mar 20 08:40:45 MAHomeLab kernel: BTRFS error (device loop3): open_ctree failed Mar 20 08:40:45 MAHomeLab root: mount: /var/lib/docker: can't read superblock on /dev/loop3. There are also errors reading from the SSD: Mar 20 08:40:52 MAHomeLab kernel: BTRFS error (device nvme0n1p1): parent transid verify failed on 761778012160 wanted 5863377 found 5857159 Mar 20 08:40:52 MAHomeLab kernel: repair_io_failure: 2 callbacks suppressed Mar 20 08:40:52 MAHomeLab kernel: BTRFS info (device nvme0n1p1): read error corrected: ino 0 off 761778012160 (dev /dev/nvme1n1p1 sector 2564352) Mar 20 08:40:52 MAHomeLab kernel: BTRFS info (device nvme0n1p1): read error corrected: ino 0 off 761778016256 (dev /dev/nvme1n1p1 sector 2564360) Mar 20 08:40:52 MAHomeLab kernel: BTRFS info (device nvme0n1p1): read error corrected: ino 0 off 761778020352 (dev /dev/nvme1n1p1 sector 2564368) Mar 20 08:40:52 MAHomeLab kernel: BTRFS info (device nvme0n1p1): read error corrected: ino 0 off 761778024448 (dev /dev/nvme1n1p1 sector 2564376)