itimpi

If you can get to the console then you can also generate the diagnostics using the ‘diagnostics’ command and they get put into the ‘logs’ folder on the flash drive. don’t enable the auto-start as it is probably a good idea to have it off while investigating any issue. I just wanted to make sure it was intentional.

Do those diagnostics include you trying to start in normal mode to see what error might be generated? I also note that auto-start is disabled - I assume this is intentional

The problem report for Polish seems to be the standard GUI pause functionality and nothing to do with the plugin? I will look into seeing if I can spot what might be wrong with the French translation file not appearing to work.

Not sure what you mean by ‘the array is not starting’? I would suggest you provide a screenshot of the Main tab and a copy of your system’s diagnostics zip file (obtained via Tools->Notifications) attached to your next post so we can give you some informed feedback.

That is a good sign - no mention of corruptions of a sort that might lead to data loss. If you run again without the -n and adding the -L option I would expect that when you restart in normal mode all the content of the drive will be accessible.

the normal way to make files persist across a reboot is to put them on the USB drive, and then add entries to the config/go file on the flash to copy them to the runtime position and if necessary set any permissions required.

you should not use the browser used to run the GUI when booting in GUI mode to access the internet. if you are also running then I assume you will be running a VM? That VM should have the same sort of security software installed you would use on a normal PC.

Make sure that any shares that have files on the cache have their Use Cache setting = Yes. That will mean mover will overnight transfer files for that share from cache to array. If you have no shares that fit that category then posting your system’s diagnostics zip file (obtained via Tools->Diagnostics) might get more informed feedback.

That is strange - the 'runtime' quoted by the plugin should basically be the same as running it straight through as all the plugin is doing is applying pause/resume operations. I guess one possibility is that you have some operations (e.g. overnight mover) running in parallel during the active periods that are slowing down the parity check speed?

The diagnostics show that you are getting continual errors (and resulting retries) on disk6. There is no SMART information for this drive suggesting it has dropped offline for some reason. This can be as a result of a bad connection to the drive or it could be a problem with the drive itself. Note that a bad connection can result from a cable (either SATA OR power) not being well seated as well as from a dodgy cable! You will probably have to power cycle the server to get that drive back online. If you want to test the drive itself then the extended SMART test is the best way to do this.

You cannot as the parity drive does not have a file system. The comment was about the fact that if you run a repair against an array data drive using the command line then it is better to use the /dev/mdX type name rather than the /dev/sdX1 type name as the /dev/mdX type does not need the partition number to be included (avoiding a common error) and also (more important) updates parity as the repair runs so that parity remains valid. It can also be run against emulated drives if needed. This suggests you have some underlying problem - you are likely to get better informed feedback if you attach your systems diagnostics zip file (obtained via Tools->Diagnostics) taken while the system is showing the problem to your NEXT post.

According to the syslog you have file system corruption on disk2. You would need to run a file system repair to fix that. you mentioned a drive replacement - which one and what was the trigger for deciding to do that?

I would still recommend using the GUI rather than the command line as then it automatically handles getting the device name right for you.

Because this would run exactly the same check, but invalidate parity so no real point. The problem is that there is no indication that there had been a problem at the file system level until it is detected later when trying to read (or write) to the disk after the problem has occurred and by that point the parity has already been updated with whatever invalid sector caused the corruption.

That command is incorrect! It should have been xfs_repair -v /dev/sdi1 That extra '1' on the end indicating the partition is important! Doing it from the GUI is much easier and less error-prone.

Most of the time the file system repair works fine and their is little if no data loss. At the very least you should run the check as that will give you an idea of whether any damage to the file system will be recovered without issue.

Probably not if there has been no write failures then Unraid parity also reflects the file system level corruption. Have you tried the process given in the link earlier to repair a damaged file system?

Are you running a trial licence or a paid for license? The trial licence DOES require internet access, but paid-for licenses do not. If you have a paid for licence then something else is going on that is accessing the internet as unraid does not then need to access the internet while starting up.

Did you run the xfs_repair from the command line or from the GUI? If run from the command line you will get those symptoms if you omit that partition number.

No - parity only kicks in if a read or write to a disk fails. In this case that has not happened and the problem is at the file system level where bad data has been written to the drive (and parity updated to reflect this). Parity has no concept of file systems as it works at the raw sector level so can never recover individual files - just the whole of a failed disk.

The Unassigned Devices plugin relies on the USB enclosure passing through different disk serial numbers for each device. It appears that enclosure is not doing this which is why you are getting the results you see so it must be considered as being not compatible with Unraid.

Handling of unmountable drives is covered here in the online documentation accessible via the ‘Manual’ link at the bottom of the Unraid GUI. This has nothing to do with parity as that is only responsible for handling ‘failed’ drives (which be marked with a red ‘x’ in the GUI), not file system level corruption.

If the server reboots itself then that nearly always indicates a hardware issue of some sort. I would think commonest is bad RAM, although in the current weather thermal shutdowns due to inadequate cooling may also be a culprit.

That is good news as it proves that UnRaid is basically booting successfully hopefully someone who has similar hardware might be able to give suggestions as to why you cannot get output on the local console.

Those diagnostics just show the system starting up and then waiting for the user to do something. The array has not even been started as auto-start is disabled.