itimpi

You could probably safely just delete (or rename) monitor.ini and let a new one be created by going to Settings->Display and making sure the settings there are what you want and hitting Apply. The diagnostics should still be supplied to see if they show other issues.

Looks like you have problems with your flash drive: Apr 6 17:45:31 Battlestar kernel: critical medium error, dev sda, sector 60125056 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2 Apr 6 17:45:31 Battlestar kernel: buffer_io_error: 2 callbacks suppressed Apr 6 17:45:31 Battlestar kernel: Buffer I/O error on dev sda1, logical block 60123008, async page read Apr 6 17:45:31 Battlestar kernel: sd 14:0:0:0: [sda] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=DRIVER_OK cmd_age=0s Apr 6 17:45:31 Battlestar kernel: sd 14:0:0:0: [sda] tag#0 Sense Key : 0x3 [current] Apr 6 17:45:31 Battlestar kernel: sd 14:0:0:0: [sda] tag#0 ASC=0x11 ASCQ=0x0 Apr 6 17:45:31 Battlestar kernel: sd 14:0:0:0: [sda] tag#0 CDB: opcode=0x28 28 00 03 95 6f 81 00 00 07 00 Apr 6 17:45:31 Battlestar kernel: critical medium error, dev sda, sector 60125057 op 0x0:(READ) flags 0x0 phys_seg 7 prio class 2 Apr 6 17:45:31 Battlestar kernel: Buffer I/O error on dev sda1, logical block 60123009, async page read Apr 6 17:45:31 Battlestar kernel: Buffer I/O error on dev sda1, logical block 60123010, async page read Apr 6 17:45:31 Battlestar kernel: Buffer I/O error on dev sda1, logical block 60123011, async page read I would suggest first try redoing it from your backup (if you have one) as sometimes rewriting the drive can fix this type of issue. If that does not work you will have to consider transferring your setup to a new one.

The Passed status on that page is rarely meaningful as it only tends to say anything else when you are in danger of catastrophic failure. To get a good indication of a drives health from SMART you need to run the extended test and only if that completes without error is it normally safe to assume the drive is OK.

The syslog in the diagnostics is the RAM version that starts afresh every time the system is booted. You could enable the syslog server (probably with the option to Mirror to Flash set) to get a syslog that survives a reboot so we can see what leads up to the problem. The mirror to flash option is the easiest to set up (and if used the file is then automatically included in any diagnostics), but if you are worried about excessive wear on the flash drive you can put your server's address into the remote server field and log to a share instead. That might help us determine if there is anything pointing to a particular hardware issue although typically with hardware issues nothing gets logged.

Restarting from the beginning is Unraid default behaviour for all array level operations. If you have the Parity Check Tuning plugin installed then it has an option to try and restart array operations from point previously reached (as long as the shutdown was a clean one).

Preclear is a good way to stress test writing to a drive before using it to store data. The extended SMART test is also a good way to do a test on a drive in a none-destructive manner. You should not be using any drives that fail the extended SMART test.

Good point. If any docker container had something mapped to /mnt/cache then that location would be created in RAM when the container starts and then appdata files placed there as well with the current settings of the ‘appdata’ share. Such files would not survive a reboot. If there is no cache pool then the settings for the ‘appdata’ share should be changed so that Primary Storage is the array and there is nothing set for Secondary storage. In addition if any docker container had something mapped to a /mnt/cache location then the mapping should instead be changed to use a /mnt/user location which works regardless of whether the files are on the array or a pool.

A cache drive is never needed. It is normally used to increase the performance of VMs and Docker containers and to improve the perceived performance of writing new files to shares by shifting the writing of them to the array to an overnight task. No obvious reason from your description why the containers should have been reset. Having said that anything important should be backed up - parity is not a substitute for backup.

An unassigned drive is one that is NOT part of the array. Rather than try anything clever and you have no free slots it is probably easiest to plug the old drive on via USB (probably using a USB->SATA dock or adapter). Less chance of doing anything wrong that way, and anyway being able to temporarily plug a drive in is always useful for purposes such as backups.

The only easy thing I could think of would be to mention checking the Minimum Free Space setting in the message saying it is running out of space. If that was done it could probably distinguish the case where it was the setting at the share level or the pool level that is relevant.

Not sure I agree it is a minor error running out of space on a pool is known to sometimes cause corruption of the pool which can lead to data loss. This is particularly the case when no value is set for the Minimum Free Space so it is getting down to close to zero. The whole idea is to keep the system as a whole functional (which it was as it was just docker having problems) and tell you about the sub-system having problems. In terms of diagnosis the error messages were complaining about lack of space, so I simply checked the share settings to see how much space you had said needs to be kept free and then how much was actually free. Note also that there is a Minimum Free Space setting at the pool level as well as the share level, so you might want to check both of them are set appropriately.

The error message is correct because for appdata (for instance) you have: shareFloor="98100000" and you do not have that much free space on the 'cache' pool. Change Minimum Free Space for the share to a lower value or make more space free.

Not quite what you asked for, but for your use case it might be worth switching the GUI to tabbed view as that limits the size of individual pages.

The recent write-up on USB flash drives mentioned that with the modern flash drives the controller on the drive is doing a continual activity even when the flash drive is NOT being read-written and this can keep them heated up which is not good for them. How severe this is in affecting the life of the flash drive I have no practical experience of as I have USB2 drives with metal casings that I use for myself.

Did you correct the syslog settings and put localhost into the Remote Server field?

I suggest posting a screenshot of your syslog settings. It is not uncommon for them not to be correct for a server to log to itself.

The main point is that it cannot be removed while Unraid is running. UD devices are typically ones you expect to be removable whenever wanted.

Not as far as i know as the boot device needs to be permanently attached. You could instead assign the UD device to a pool and then it can be used for booting.

The default Unraid behaviour is to restart any array operation if the system is rebooted before it finishes. The Parity Check Tuning plugin does have an option to restart array operations from the point reached, but it will only do so if you manage a clean shutdown and this is unlikely to be achieved if you are getting a disconnecct.

Just that they are one of the brands that are most often counterfeited. With modern Sandisk drives they share the problem (along with all other brands) of their newest drives being less robust for 24x7 use use than their older ones.

If configured as expected then the docker.img file only contains the binaries for containers, appdata contains the containers working storage.

The safest thing would be to set the problem drives to never spin down.

Your screenshots do not show what is taking up the 6.5GB in /var/log mentioned in the last screenshot. Whatever it is is almost certainly the problem.

The syslog in the diagnostics is the RAM version that starts afresh every time the system is booted. You should enable the syslog server (probably with the option to Mirror to Flash set) to get a syslog that survives a reboot so we can see what leads up to the problem. The mirror to flash option is the easiest to set up (and if used the file is then automatically included in any diagnostics), but if you are worried about excessive wear on the flash drive you can put your server's address into the remote server field and log to a share instead.

You see these whenever a docker container starts up. If you are getting them continuously then you have one or more containers crashing and restarting.