BRiT

We'd rather not download arbitrary files from external and possibly questionable sites.

You should likely get your own topic thread since many users are less likely to post in threads already marked as SOLVED.

UD is Unassigned Devices plugin.

For reference of 1 such instance:

Do you have your server exposed to the internet? There has been situations where ki d users have found other unraid servers unprotected on the internet and as an act of kindness had shut them down to prevent malicious others from destroying all data.

Did you do a hard power cycle, like actually turn power off for a minute and then back on when testing? Maybe device got working once and will continue to work across presets until power is hard cycled?

Maybe entirely silly question and not related at all, but for everyone who has the SQLLite Corruption what filesystem are you using on the drives where the DB resides? Is everyone with corruption using BTRFS? Anyone experiencing corruption using XFS on their drives? Maybe this is like the pesky issue dealing with COW or RFS years ago?

If you have the same problem, then the solution is the same, uninstall atop.

Now having looked at your Diagnostics, your USB Flash drive has issues. Jul 22 14:16:54 Tower kernel: scsi 0:0:0:0: Direct-Access USB 2.0 SD/MMC Reader PQ: 0 ANSI: 0 CCS Jul 22 14:16:54 Tower kernel: sd 0:0:0:0: Attached scsi generic sg0 type 0 Jul 22 14:16:54 Tower kernel: sd 0:0:0:0: [sda] 1984000 512-byte logical blocks: (1.02 GB/969 MiB) Jul 22 14:16:54 Tower kernel: sd 0:0:0:0: [sda] Write Protect is off Jul 22 14:16:54 Tower kernel: sd 0:0:0:0: [sda] Mode Sense: 03 00 00 00 Jul 22 14:16:54 Tower kernel: sd 0:0:0:0: [sda] No Caching mode page found Jul 22 14:16:54 Tower kernel: sd 0:0:0:0: [sda] Assuming drive cache: write through Jul 22 14:16:54 Tower kernel: sda: sda1 Jul 22 14:16:54 Tower kernel: sd 0:0:0:0: [sda] Attached SCSI removable disk ... Jul 22 14:16:54 Tower kernel: sd 0:0:0:0: [sda] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 Jul 22 14:16:54 Tower kernel: sd 0:0:0:0: [sda] tag#0 Sense Key : 0x3 [current] Jul 22 14:16:54 Tower kernel: sd 0:0:0:0: [sda] tag#0 ASC=0x11 ASCQ=0x0 Jul 22 14:16:54 Tower kernel: sd 0:0:0:0: [sda] tag#0 CDB: opcode=0x28 28 00 00 03 68 c7 00 00 01 00 Jul 22 14:16:54 Tower kernel: blk_update_request: critical medium error, dev sda, sector 223431 Jul 22 14:16:54 Tower kernel: sd 0:0:0:0: [sda] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 Jul 22 14:16:54 Tower kernel: sd 0:0:0:0: [sda] tag#0 Sense Key : 0x3 [current] Jul 22 14:16:54 Tower kernel: sd 0:0:0:0: [sda] tag#0 ASC=0x11 ASCQ=0x0 Jul 22 14:16:54 Tower kernel: sd 0:0:0:0: [sda] tag#0 CDB: opcode=0x28 28 00 00 03 68 c7 00 00 01 00 Jul 22 14:16:54 Tower kernel: blk_update_request: critical medium error, dev sda, sector 223431 Jul 22 14:16:54 Tower kernel: sd 0:0:0:0: [sda] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 Jul 22 14:16:54 Tower kernel: sd 0:0:0:0: [sda] tag#0 Sense Key : 0x3 [current] Jul 22 14:16:54 Tower kernel: sd 0:0:0:0: [sda] tag#0 ASC=0x11 ASCQ=0x0 Jul 22 14:16:54 Tower kernel: sd 0:0:0:0: [sda] tag#0 CDB: opcode=0x28 28 00 00 01 b0 c7 00 00 01 00 Jul 22 14:16:54 Tower kernel: blk_update_request: critical medium error, dev sda, sector 110791 Jul 22 14:16:54 Tower kernel: sd 0:0:0:0: [sda] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 Jul 22 14:16:54 Tower kernel: sd 0:0:0:0: [sda] tag#0 Sense Key : 0x3 [current] Jul 22 14:16:54 Tower kernel: sd 0:0:0:0: [sda] tag#0 ASC=0x11 ASCQ=0x0 Jul 22 14:16:54 Tower kernel: sd 0:0:0:0: [sda] tag#0 CDB: opcode=0x28 28 00 00 01 b0 c7 00 00 01 00 Jul 22 14:16:54 Tower kernel: blk_update_request: critical medium error, dev sda, sector 110791 Jul 22 14:16:54 Tower kernel: sd 0:0:0:0: [sda] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 Jul 22 14:16:54 Tower kernel: sd 0:0:0:0: [sda] tag#0 Sense Key : 0x3 [current] Jul 22 14:16:54 Tower kernel: sd 0:0:0:0: [sda] tag#0 ASC=0x11 ASCQ=0x0 Jul 22 14:16:54 Tower kernel: sd 0:0:0:0: [sda] tag#0 CDB: opcode=0x28 28 00 00 03 68 07 00 00 a8 00 Jul 22 14:16:54 Tower kernel: blk_update_request: critical medium error, dev sda, sector 223239 Jul 22 14:16:54 Tower kernel: sd 0:0:0:0: [sda] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 Jul 22 14:16:54 Tower kernel: sd 0:0:0:0: [sda] tag#0 Sense Key : 0x3 [current] Jul 22 14:16:54 Tower kernel: sd 0:0:0:0: [sda] tag#0 ASC=0x11 ASCQ=0x0 Jul 22 14:16:54 Tower kernel: sd 0:0:0:0: [sda] tag#0 CDB: opcode=0x28 28 00 00 03 68 07 00 00 08 00 Jul 22 14:16:54 Tower kernel: blk_update_request: critical medium error, dev sda, sector 223239 Jul 22 14:16:54 Tower kernel: sd 0:0:0:0: [sda] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 Jul 22 14:16:54 Tower kernel: sd 0:0:0:0: [sda] tag#0 Sense Key : 0x3 [current] Jul 22 14:16:54 Tower kernel: sd 0:0:0:0: [sda] tag#0 ASC=0x11 ASCQ=0x0 Jul 22 14:16:54 Tower kernel: sd 0:0:0:0: [sda] tag#0 CDB: opcode=0x28 28 00 00 03 68 07 00 00 08 00 Jul 22 14:16:54 Tower kernel: blk_update_request: critical medium error, dev sda, sector 223239 ... Jul 22 14:17:02 Tower emhttp: import flash device: sda ... Jul 22 14:21:53 Tower kernel: blk_update_request: I/O error, dev sda, sector 110855 Jul 22 14:21:55 Tower kernel: blk_update_request: I/O error, dev sda, sector 111095 Jul 22 14:21:58 Tower kernel: blk_update_request: critical medium error, dev sda, sector 110791 Jul 22 14:30:25 Tower kernel: blk_update_request: I/O error, dev sda, sector 111303 Jul 22 14:30:27 Tower kernel: blk_update_request: I/O error, dev sda, sector 111495 Jul 22 14:30:34 Tower kernel: blk_update_request: critical medium error, dev sda, sector 110791

I have not looked at your diagnostics, but typically something like this is caused by being unable to write the current configuration to your USB Flash drive. You may need to post up new Diagnostics after you make changes in the UI but BEFORE you reboot the server, that is to see if there are any errors of being unable to write to the USB Flash.

Navigate to the Docker page, a direct link if your unraid server is named Tower would be -- http://Tower/Docker

Can you post current Diagnostics after the issue happens?

Stop spreading FUD. It does not serve anyone's purpose.

Yes. You can mix and match at will.

Seems to be related to Plex if the other thread is accurate.

Yup, and all that has to be supported by the unRAID md block driver as specified by the requirements on the link you posted. So it's not trivial as you think. Requirements The block device underneath the filesystem must support the FITRIM operation.

Look into User Scripts addons. It's easier to manage your own items via that plugin.

Dont browse sketchy sites on accounts having write access to files.

Not trivial at all when you can't guarantee how the SSDs behave when a "trim" command is sent to them. Taking the disk offline, trimming it, and putting it back online can Frak up your Parity protection.

Its /gcsp/ not gscp. GSCP is a GoodSync thing. What's in the Diagnostics that was attached is actually /gcsp/2.0

Happens using Win10 OS with Edge using Chrome Engine Dev branch too. Nothing else running on my desktop, so it's not cpu intensive on the client.

This entire plugin thread says otherwise:

WTF Hack: append line into /etc/password for a new user with the shell set to /sbin/shutdown this way whenever that user logs in the system will shutdown. 🤣

You could delete the docker image, recreate it, and all them all back via CA, make sure none of them run, then get a new reference list of sizes called Point 0. Then start the dockers and check after 15 minutes for reference Point 1. Then check back tomorrow morning for reference Point 2. Repeat again after a day for Point 3. None of the sizes should drastically change from Point 1. I would expect the sizes to be much smaller than in your initial Post.

The reason I said to do it one at a time is you obviously have something wrongly mapped on at least one of the dockers. There's no reason to need more space on the actual docker.img. Everything that requires large amounts of space should be mapped through outside the docker container. If you dont review and correct the wrong mapping(s) you will continue to have your original issue.