itimpi

If you are talking about group 14 in the screenshot then that is probably because that group cannot be passed through to a VM. For pass-through to work you have to pass through every device in the group and that will not be viable for that group.

Should the second /mnt/user/... actually be /mnt/cache/... ? Does not seem to make sense otherwise

If you go into the Advanced view on Settings->Docker then you can: change the startup order using drag-and-drop set a delay AFTER starting a container before attempting to start the next one.

Carry out this procedure against the rebuilt disk and report back on how it goes.

Sounds as if you have a hardware error as Unraid should never restart on its own. I would suspect power or cooling. If you want diagnostics that survive a restart then you should set up the syslog server.

Not much point as the rebuild process would overwrite every sector on the disk thus destroying the result of a format or clear if done outside the array. If done with the disk IN the array you would end up erasing all its contents with no way to recover the data. Follow the advice from @trurl for the next steps to take.

No - the parity drive contains no user data and does not work at the file level. It works at the whole drive level to restore the expected bit pattern after a drive fails. It cannot handle anything that works at a different level. you should always have backups for anything important to you - parity is not a substitute for backups. If you have the CA Backup plug-in installed it might have made a backup of the containers appdata folder that is still available? the system crashing during a parity check should not have caused data loss. Something else must have happened to cause that.

Use the ‘Only’ setting! note you should only use this setting once there are no files currently on the array for the share as the ‘mover’ application ignores shares set to,’Only’.

Not sure It looks like you might have misunderstood the Prefer and Yes settings for the Use cache setting? - Yes means write them to cache with overflow to array. Later move any files on cache to the array - Prefer means write them to cache, with overflow to array. Later move any files on array to cache if sufficient free space.

On a new install with no licence active it is not unreasonable for no drives showing The diagnostics showed that drives were being detected. I would suggest putting the activated flash drive into a PC/Mac and let it scan for any corruption. If none found then diagnostics while using that drive might give a clue.

You are continually getting messages like : Dec 17 10:08:41 Tower kernel: ata5: lost interrupt (Status 0x50) Dec 17 10:08:41 Tower kernel: ata5.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen Dec 17 10:08:41 Tower kernel: ata5.01: failed command: READ DMA EXT Dec 17 10:08:41 Tower kernel: ata5.01: cmd 25/00:f8:18:26:93/00:03:13:00:00/f0 tag 0 dma 520192 in Dec 17 10:08:41 Tower kernel: res 40/00:01:01:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout) Dec 17 10:08:41 Tower kernel: ata5.01: status: { DRDY } Dec 17 10:08:41 Tower kernel: ata5: soft resetting link Dec 17 10:08:41 Tower kernel: ata5.00: configured for UDMA/133 Dec 17 10:08:41 Tower kernel: ata5.01: configured for UDMA/33 Dec 17 10:08:41 Tower kernel: ata5: EH complete in the syslog. I believe ata5 is the parity disk. This suggests either a connection problem (most likely) or the drive itself playing up.

Looks like there might be a problem with the flash drive as the syslog contains Dec 17 11:56:27 Tower emhttpd: Unregistered Plus - invalid key (EGUID)

Rebuild speed should similar to a parity check speed as long as there is nothing else happening on the array at the same time. Your speed suggests there is something else going on affecting the speed. Attach your system's diagnostics to you next post to get informed feedback.

Unfortunately not as by default logs are only in RAM and thus lost on reboot. If you want persistent logs then you can set up the syslog server.

The syslog is full of messages warning you about file system corruption on disk2 (md2). You should run a file system check/repair on that drive. The process is coveted here in the online documentation accessible via the ‘Manual’ link at the bottom of the GUI, but ask questions if there is anything you are not sure of.

Since this is about security it is a good idea to be a bit paranoid How about giving two links - one to view the script and the other to download it. That makes it easy to check it out before downloading it. If the script ends up being simple you could even include it in its entirety within the documentation.

I must admit I had not thought of applications providing their own JRE Maybe just make the point that it applies to applications programmed using the Java language?

I agree it looks like it should work You could try changing the mapping to use /mnt/docker/downloads instead of /mnt/user/downloads so it is by-passing the User Share handling level?

Is it not worth mentioning that you can first check to see if you even have Java installed in the first place? If that is not present then you do not need to go any further.

If you do not export those shares then the security setting is not relevant. If you do want to export them then your ideas make sense.

A pending sector is one whose contents could not be read reliably. Can be corrected when the sector is next written, and if not the sector might then be reallocated instead.

Just for interest will this be for the whole run or just the last increment? Just asking to see if I might need to revisit the code in the Parity Check Tuning plugin that tries to give the correct values for the run as a whole.

It could be worth carrying out file system checks on all drives (including any pools) as file system level corruption has keen known to interfere with share visibility

Mis-read that one It might be worth providing the docker run commands for the nzbget and qbittorrent containers so we can see all the mappings they are using if it is thought one of them is the culprit.