itimpi

Your syslog is full of errors that start with May 22 00:14:03 homeserve kernel: DMAR: ERROR: DMA PTE for vPFN 0xf2827 already set (to 200000000000 not 758ed9002) May 22 00:14:03 homeserve kernel: ------------[ cut here ]------------ May 22 00:14:03 homeserve kernel: WARNING: CPU: 2 PID: 21150 at drivers/iommu/intel-iommu.c:2300 __domain_mapping+0x205/0x2dd Not sure what causes this, but they should not be happening on a well-behaved system.

That /boot/packages line is not part of a standard go file. It is probably what causes the other error messages you mentioned as tightening of Unraid security a few releases ago means that files on the flash dtive can no longer have ‘execute’ permission set on them.

You might want to check your ‘go’ file in case there are any other references to incompatible/obsolete features? also do you have an ‘extras’ folder on the flash drive. If so that should probably be removed as it may be installing incompatible packages. In v6 any extra packages are normally installed via the Nerdpack or DevPack plugins.

How much space have you allocated for the vdisk? That error message sounds as if it may be too small?

Why do you have any reference to unmenu in your config/go file on the flash drive? Unmenu was a v5 feature that is not compatible with the current v6. Any reference to it should be removed as trying to use it will just cause problems.

Are you using a HBA? If so have you disabled the option to boot from HBA attached drives? I have come across cases where the BIOS gets confused if it finds more than 12 devices that could be potential boot devices.

Logs do not survive a reboot unless you set up the syslog server under Settings. however the machine powering itself off has to be a hardware issue. The two obvious candidates are the CPU fan not working properly causing the CPU to overheat and turn the system off, or an insufficient/faulty power supply.

You probably have incorrect permissions on the files since you did not load the files over the network. run Tools >> New Permissions on the shares you have just loaded and that should correct any permission issues.

Barrier seems to have a dependency on qt5 which I would think would preclude it from NerdPack?

If you are running any VMs that are using hardware pass-through then you need to be aware that the hardware IDs are likely to change. You definitely want the VM service stopped until you can check this out. other than that it should ‘just work’ as Unraid is largely hardware agnostic.

I did not spit anything obvious in the syslog you posted. However that is NOT the diagnostics that are a zip file obtained via Tools >> Diagnostics which contain a lot more about your system (and includes the syslog as part of the information). The description of an initial fast burst and the speed then dropping suggests that at first the data is being buffered in RAM, and then once that has filled the speed drops. No idea why this is happening for you

It is normally recommended that SSDs are attached to motherboard ports because as well as solving the trim issue they also tend to give the best performance.

A red ‘x’ next to a drive means that Unraid is no longer reading or writing to the drive and Unraid has stopped using it. Running a parity check in such a case does not touch the disabled drive - it merely checks that all the other drives can be read without error. The procedure for clearing the disabled state is covered here in the online documentation.

The rebuild process has to rewrite every sector on the target disk, so you should expect it to take a similar amount of time to a parity check. In addition, any other activity on the array will slow the process down just as it would slow a parity check.

That is good as the rebuild process just puts what you can see on the ‘emulated’ disk back onto a physical drive. The process for doing this is documented here in the online documentation. if you have a spare disk it is always safest to rebuild to the spare and keep the original intact in case anything goes wrong during the rebuild process as then you have the original intact for data recovery purposes. This is not always practical if the drive appears to not actually be faulty, so often as long as the SMART information looks OK rebuilding the disk back to itself is often an eminently reasonable thing to do.

This means that Unraid is constructing what it thinks should be on that drive by the combination of parity plus all the other data drives. You should see if you can browse the ‘emulated’ drive in the GUI and see its contents? If not then let us know so we can give advice on best way to proceed. If the emulated contents look OK then you have the choice of rebuilding the emulated disk contents either back to the same disk or to a replacement. If you cannot see the emulated contents then the next steps will be slightly different. The SMART information for that drive looks OK. The most frequent cause of a disk being disabled is due to the SATA/power cabling having issues rather than the disk itself being faulty, so you want to check that out carefully.

A few points to help you decide: a disk is disabled when a write to it fails as at that point it is now out of step with parity. At this pointUnraid stops writing to the drive and will now start emulating the drive using the combination of the other drives plus parity. Subsequent writes to this emulated drive are reflected in parity only and the disabled drive is left untouched. A drive being Unmountable indicates some sort of. Irruption at the filing system level. The rebuild process will not correct this. The rebuild process just puts back on the physical drive the contents of the emulated drive so if the emulated drive is unmountable then the rebuilt one will be as well. you can attempt the file system repair process on the emulated drive prior to any rebuild attempt. Only if this is successful does the rebuild makes sense. it is always possible the disabled disk does not have the file system corruption, but it only contains any data written before it became disabled. Rebuilding to a new disk leaves the original disabled disk untouched giving you other recovery options if this does not resolve the issue

Attach your system diagnostics zip file (obtained via Tools >> Diagnostics) to your next post in this thread so we can see what is going on.

what you have just done is what is wanted. Some people add it to the original post, and then that gets missed as doing so does not cause the thread to be marked as having new cobtent.

If you are reasonably certain that parity is valid you can check that option. I would still recommend running a parity check to confirm it really is valid.

The syslog is full of messages indicating you have corruption on your nvme device (which I assume is your cache device?).

You can ignore that error. If you have the parity-check-tuning -plugin installed you will get that message as it gets involved when mdcmd is invoked and it has a tiny bug in that it does a divide at one point without first checking the divisor to be non-Zero (which can be the case if no parity check is currently running). Other than the false error message there is no other side-effect.

Only the root user (i.e. Administrators) can successfully log into the Unraid Web GUI in the first place.

You might find this section of the online manual to be of use?

That shows the disk is failing the test and should be replaced ASAP.