itimpi

There is normally a BIOS setting that allows you to operate without a keyboard. Assuming you want to run headless then you can use a "Dummy HDMI plug" to make the system think a monitor is connected.

There is comprehensive documentation accessible via the ‘manual’ link at the bottom of the Untaid GUI. All the information you need should be in the Storage Management section.

Did you actually run xfs_repair without -n and with -L? All the examples of the xfs_repair output you gave earlier indicated that -n had been used so no changes were being made. The xfs_repair is normally very fast - just a few minutes. Despite the ominous sounding warning about the -L option it virtually never causes data loss, and in the rare cases where it does it only affects the last file being written.

Something strange going on - the syslog in those diagnostics is the same as the one in the earlier one? Since you can get to the console maybe you need to directly get the current syslog from /var/log/syslog via the console to see if it is different.

If the drive is no longer showing as unmountable can you see any contents? Just guessing as you seemed to have missed the attachment you mention.

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.