itimpi

The idea behind Highwater was to both keep related files together, and also to avoid having more disks spun up than necessary when writing files.

What makes you think it should have been used? As far as I can see your shares are set to use Highwater allocation method. Since your largest disks are 10TB, the disks start switching at 5TB, 2.5TB, 1.25TB etc. On this basis disk11 will not start getting used until all the lower numbered disks have less than 2.5TB free (which is not currently the case as disk1 and disk2 have more than that free).

You can control at the individual share level whether new files written to that share are first written to the cache (and later moved to the array) or whether they by-pass the cache and go straight to the array. That means you can achieve the balance you prefer between performance and risk.

Looks like you are going to need to run the repair with the --rebuild-tree option (and without the -n option which means act only as a check) BTW: If you want to retain the layout when posting such results use the code option the </> button)

Not sure why they would but file system corruption often seems to mess up the User share views. You mentioned earlier clicking on the drive on the Main tab to see the files. You did not mention what happened if you tried to go via the Shares tab to go via a User Share.

If you want any such change to survive a reboot then you need to make a copy of the file(s) on the flash drive and add an entry to the ‘config/go’ file on the flash drive to copy it into position (and potentially set correct permissions) as part of the system start up process. Since Unraid does not support traditional users in the Linux sense not sure what you have done to allow you to log in with a non-root user.

The log show that you definitely have file system corruption on disk5. The procedure to confirm this is: stop the array restart the array in maintenance mode click on disk5 on the Main tab to get to the dialog where you can run a file system check assuming you want to first run a check to confirm the corruption simply click on the option to start it. If you want to go straight into the repair stage then remove the -n flag and start the repair. This can take a long time (potentially hours) so do not get impatient. when the repair finishes stop the array and restart in normal mode. if you get any errors reported then you should check back before proceeding. Depending on the level of corruption you may find that you now have a lost+found folder on the drive. That is where the repair process puts any files for which it cannot find the directory information to know what their name was.

I think this may already be fixed in the 6.8.0 rc series.

Did you get the diagnostics before you rebooted? It looks to me as though you may only have taken them after the reboot, and by that stage the syslog is lost as the it is only in RAM.

I would suggest you post your system diagnostics zip file (obtained via Tools >> Diagnostics) if you want any sort of informed feedback. At a guess I would suspect some sort of file system corruption.,that needs the appropriate check/repair tool to be run, but the diagnostics would confirm that.

Another thing you can do is set a delay on a docker that should be used after starting it before attempting to start the next one. This can be important if you need some dockers to initialise before others start.

The commonest cause is some sort of connection glitch that causes a write to fail. In such a case you end up with the disk disabled, and frequently unmountable until you run the file system repair utility. The cause of such things can be widely varied although cabling issues are amongst the most common.

Since to error was reported then the disk should now be mountable - is this the case?

All attached storage devices (except the boot drive) count regardless of whether they are being used by Unraid or not.

I have never heard of that behavior where multiple checkboxes at the same level are checked when you click the top one. Are you sure you do not mean clicking a checkbox selects all sub-levels? Do you have an example of a program that gives the behavior you describe? I HAVE heard of clicking the top one and then SHIFT-Clicking a lower one to select both clicked items and all those in between. Whether that is practical to implement in a browser I have no idea.

Yes

I do not think there is currently any way to stop the RAM copy of the syslog. The syslog server simply allows a copy to also be stored elsewhere. Whether this might be a sensible future enhancement I have no idea as I am not sure what the implications might be.

I tested it by putting a copy of the key file on the flash drive and then adding a line to the start of the ‘go’ file to copy it to /root/keyfile and that seemed to work fine.

Sounds as if the file is correct then. Have you made sure it has been copied to /root/keyfile before trying to start the array. I agree x but I have been using it for so long now that it's use is almost instinctual 😁

I am not sure if nano will automatically add the end-of-line. I used vi where I could control that. A quick check is to 'cat' the file. If there is no end-of-line then the bash prompt ends up on the same line as the passphrase. If you want the array to autostart then you are going to need to add an entry in the 'go' file to copy your saved keyfile to /root/keyfile

It is critical that you. do NOT have an end-of-line character present or that will be treated as part of the key.

Not much point! The whole idea is to try and work out what is happening in the 6.8.0 rc.

I have checked on one of my test systems by creating an encrypted disk with a passphrase and it appears that the keyfile contents IS just the passphrase. Note that there is no end-of-line in the file so the file terminates at the last character of my passphrase.

The syslog seems to show that initially the server does not get an IP address issued from the DHCP server, but that later after the main boot phase completes it does. Is there anything strange about your network setup that might cause this?

OK. This is the first time I have heard of high-water allocation not working as expected that has not been tracked down as either a misunderstanding of how it works or a configuration issue.