itimpi

cannot think of any good reason the drive is reporting at one level it is a 32GB drive and at another level it is only 16GB available It might be worth checking that the drive has not been partitioned in some way and that the first partition is only 16GB.

This is almost certainly due to the Split Level you have set for the shares in question. When unRaid tries to select a disk for a file in the event of contention between settings on the share then Split Level always takes precedence. You also have the option to Exclude any specific disk(s) from a share which will stop any new files being written to that disk, but the files will still be found for read purposes.

Have you tried stopping the array?

You CAN control the order in which docker containers are started under unRaid by re-ordering them on the Docker tab and also set delays in the sequence to allow for initialisation of specific containers before continuing with loading further containers. I would have thought for most use cases this was sufficient?

You said earlier that your GPU is set up to be passed through to a GPU? If so you have probably isolated it and told unRaid to not use it for its own purposes?

I cannot replicate this. When I use Chrome with the IP address of my unRaid server I get prompted for the password.

If I read you right you want to use p7zip inside a container? If so it needs to be installed inside the container, not at the unRaid (host) level. The whole idea of containers is that they are isolated from the host software environment and handle their own software dependencies.

You said you ran a correcting check so that should have fixed the errors (unRaid shows ‘fixes’ in the error count which is a tad mis-leading). If you now run a non-correcting check it should show 0 errors indicating parity is again in sync.

You mention a ‘terminal’ so are you talking about connecting via telnet or SSH rather than a browser (or something else)? You can control whether telnet and SSH are available under Settings -> Management Access, but you should still be prompted for a password if one is set. it might be worth providing your system diagnostics zip file (obtained via Tools->Diagnostics) after such an unexpected login so we can get a better idea of what is actually going on.

Click on the flash drive on the Main tab I've often thought to myself that it should also be listed under the Disk Shares part of the Shares tab as that is a more 'discoverable' location.

Whether a browser can store passwords is set at the browser level - not in unRaid. Where that setting is in the browser will depend on the browser in use.

Sounds bad if you cannot track down where this is coming from. I would be worried that you have some other device on your local LAN (or your router) compromised and that is the way that the someone is getting into your system. The other issue is how are they getting to the flash drive to change it? Is the flash drive shared on the network so that it can be accessed from another machine/device. I would recommend it is not shared on the network unless needed and definitely do not have it shared as a public share so anyone can change its content.

If that is the case then you should now be getting prompted for a password before you can access the unRaid GUI regardless of where you access the GUI from. Are you saying this is not happening? You do want, though, to make sure that you have not allowed the browser on any machine to store the password so that it pre-fills it (which defeats the object of having a password).

Have you set a password up in unRaid for the root user (via the Users tab in the GUI) as when you first install unRaid it will have no password set. If you have set a password then it should not be possible to access the unRaid GUI from anywhere without supplying that password.

Not quite when using the raw device names (the sdX type) then you need to include the partition number so it is /dev/sdi1

Quite a lot of motherboards have trouble clocking RAM at the maximum advertised speeds when all slots are used. Therefore you can easily get the situation where the system is stable under any 2 of your RAM sticks but then has stability issues when all 4 are plugged in simultaneously.

Reformatting a drive is covered here in the online documentation accessible via the ‘manual’ link at the bottom of the unRaid webGUI.

Finally tracked down what has been causing the error line when displaying the Parity Check history. Turned out to be a hidden ESC character that had crept into the script file. Was not enough to cause a syntax check of the file to show an error, but it was enough to upset displaying the history results (deep inside one of the unRaid GUI support functions). I will shortly issue an update to fix this.

The My Servers option is brand new as it was introduced with the 6.9.x releases - in fact it is technically still in beta as the last few quirks get worked out. It is expected to be the preferred solution going forward.

Each time you transfer the licence to a new USB stick then the previous one is blacklisted. As far as I know this has always been the case.

Not at the moment as I have a system that can reproduce the symptoms.

The error displayed trying to look at the parity check history is completely divorced from the main operation of the plugin so in that sense you should not be affected by it. in addition it does not seem to be fatal even when trying to display the history. However since the line it complains about is in a file that handles multi-language support in unRaid this may not be true if you have a language other than English set in unRaid (I have not tested if this is the case). I am still trying to track down why it happens in the first place on one of my unRaid systems and not another both of which are running unRaid 6.9.1.

From your description it sounds as if the xfs_repair should have fixed it. Ideally we would have wanted diagnostics covering the point at which you booted the system to discover the unmountable drive and including the attempt to repair it and the output of that attempt. Unfortunately without that any guesses at what went wrong would just be wild guesses.

As far as unRaid is concerned I guess it will likely be a case of which Linux kernel release includes this bug fix. and then which unRaid release picks up that kernel version.

Are you accessing the server by name or IP address from your main computer? If using server name it might be worth trying the IP address in case there are some name resolution issues. If your server has a fixed IP address then using the IP address always seems to be more reliable.