itimpi

Strange as obviously the docker.img file DOES exist (i.e. it is not a new one) as otherwise the containers would have needed their binaries reloading before they could be run.

Fair enough. However I have had plenty of Unclean shutdowns on 6.12.6 which did not change the Docker service status from enabled to disabled. I will do some testing in my test environment to see if I can reproduce this happening as it looks like new (albeit probably a good idea) behaviour to me. However that does not explain the fact that after enabling the docker service I got the warning banner being displayed at the top of the Docker tab despite the fact that at that point the array is started and all docker containers appear to be working as normal. I am going to try to do some more structured testing on this but thought I should get a report in in case others also experience it so we can see a pattern.

Thanks for those diagnostics. I think I now see the issue and can see where the restart state is getting lost. If I am correct then if you simply hit shutdown/reboot rather than stopping the array first the restart information will not be lost and the operation should restart on starting the array after the next reboot. However the sequence you are following is perfectly valid so I need to do some slight rework so that the restart information is not lost when following your sequence. I think the fix is quite easy but I need to test it out to make sure I have not inadvertently broken something else in making it as tracking the state can at times be a little tricky because of interactions between the plugin and Unraid's built-in array operation handling.

They passwords are just as secure as they would be on a traditional Unix/Linux system as they are only ever stored in encrypted form. It is just that Unraid makes a copy of the passwd and smbpasswd files onto the flash drive so that it can be restored after a reboot. If they can be decrypted there the same files could be decrypted on any system and this does not seem to be something that happens.

If a drive cannot pass a SMART test (Short or long) then it we normally recommend it should be replaced. There is also this in the SMART information: 197 Current_Pending_Sector -O---K 100 100 000 - 16 which is concerning as any recovery after a data drive failure would require it to be read error free to avoid data loss. It is always possible that rewriting the Pending sectors would cause them to be cleared so you could try doing a preclear on the drive to rewrite it to see if that helps, but even if that worked I would still keep a close watch on the drive.

I am assuming that you used the New Config tool? If so and you ticked the checkbox to say parity is valid then the parity will not get overwritten despite the warning as that message does not take account of the checkbox.

This is true as far as it goes. The normal answer is to install the CA Backup plugin to backup the 'appdata' share that is on cache elsewhere (typically the main array) at scheduled intervals.

Not sure if you are saying you eventually got an error or not?

Could not spot anything obviously wrong, but you need to make sure that you have disabled the docker and VM services under Settings as they keep files open which will stop them being moved. BTW: You have a lot of .cfg files in the config/shares folder on the flash drive for shares that currently do not exist. Deleting these will tidy up that part of the diagnostics and make it easier to spot relevant information.

You should post your system's diagnostics zip file in your next post in this thread to get more informed feedback. It is always a good idea to post this if your question might involve us seeing how you have things set up or to look at recent logs.

If you have more than one RAM stick then it can be worth trying them individually to see if they can then pass memtest.

Yes - even 1 error in memtest is too many and once you have memory errors the symptoms can be unpredictable. If you have more than 1 stick of RAM then you might try testing them individually. It is, however, not unheard of for them to test out individually but still fail when they are all plugged in - typically due then to the memory controller being overloaded.

If I understand your question correctly the answer is probably yes. They are implemented using the Linux KVM sub-system

@BrennstoffBernd In theory that was fine as it includes the syslog leading up to the shutdown, but was the Testing mode logging active in the plugin settings when you did this last test? I could not see any of the extra diagnostic information that the Testing mode generates.

What happens when you try and do this? This seems to be nothing to do with IOwait which is the subject of this thread. Perhaps posting your diagnostics after an attempt will help us spot something?

@BrennstoffBernd Looking through the diagnostics it seems there is no restart information present when the system starts back up which surprised me in light of the fact that you previously got the message that a restart would be attempted. It might be necessary to get the syslog server enabled (with the mirror to flash option) and then repeat the exercise so that I can also see what happened during the closedown process as well as what happened after the restart. Just for interest have you tried simply trying to shutdown the server without first pausing the parity check? I am going to have another go at trying to reproduce your symptoms at my end by trying to follow the exact sequence of steps you have outlined.

You would need a paid-for licence for this to work. The Trial licence requires an active internet link before it will start the array (and thus any VMs).

You might need to check that Unraid still thinbs the drive is xfs format as it might have auto-changed it to be btrfs format when you changed it to be multi-drive. If that is the case clicking on the drive (with array stopped) and changing format to explicitly be xfs may be required.

Nothing spring out as indicating a problem. Doing the Extended SMART test on a drive is a good indication that if it passes it is probably OK, and failure means should be replaced.

I cannot see any SMART report for disk3 which suggests it has dropped offline. It might be worth power cycling the server to see if that gets it back online and if it does posting new diagnostics. this does not mean there is no cabling issue - it can be just a case of the connector working itself slightly loose. You also need to check the power side of things as this can also cause issues.

I do not think this is possible. Unraid recognises disks by the combination of the serial number and size. If either value changes then it is considered to be a different drive.

I think you have misunderstood Exclusive shares? They can only apply to User Shares where all files/folders exist on a single drive or pool.

I agree that having some GUI support might be nice, but thought it was worth pointing out a way to proceed at the moment. Providing feedback on what you find doing so might help with clarifying what might be worth adding to the GUI. It is also worth pointing out that the Unraid GUI source is available on gitHub, so it is possible for anyone (not just Limetech) to add such a function by working out what needs doing and submitting a pull request. Limetech have final authority but as long as it is purely GUI changes (and thus not likely to break underlying functionality) then it would almost certainly be accepted.

You do not actually have to write a plugin! You can just create a folder on the flash drive under config/plugins and put the .page file there. A plugin is just a convenient way of packaging such files for others, and also allows for loading any software components that might be required to support the tile.