Squid

It should still work, and can be installed via CA, but if you've got any problems, they will NOT be fixed.

Jul 16 09:30:52 unraid kernel: FAT-fs (sdb1): error, fat_get_cluster: invalid start cluster (i_pos 0, start 04c8eb3d) Shutdown the server, toss the flash drive into another computer and run Check Disk on it.

Post diagnostics Sent from my NSA monitored device

Follow the first link in the Real Docker FAQ here Sent from my NSA monitored device

Has the Ebay listing been taken down and superceded with another one selling the identical item? Easy way for the sellers to avoid bad reviews on the product being sold Sent from my NSA monitored device

Enable the Syslog server to save the syslog to the flash drive (Settings Tab), then post the save syslog after it crashes again.

docker image is full or corrupted. Diagnostics will say

Post an applicable xml file from /config/plugins/dockerMan/templates-user on the flash drive that you're having problems with.

Just use user scripts and have a script that runs at whatever time with the mover stop command. Doesn't do anything if its not running.

Do you also have any cpu pinning entered in manually in the extra parameters of the template?

Keep us informed...

I have a feeling though that if the share was fully contained onto a single drive you wouldn't have had any problems with diskX Hearsay isn't usually helpful.

The share is located on disk 1 and disk 2. Try this. Make a new share for the hell of it. Only include disk 1. Point Plex to it (/mnt/disk1/NewShare) and see what happens. (IE: Start Plex over at the new share. Don't copy any of the old appdata to it)

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 29682 nobody 20 0 1892308 228748 14500 S 100.0 0.7 21:50.14 Plex Tran+ Plex is currently transcoding something.

While this may seem argumentative (and I don't mean it to be), but can you confirm this Your post on June 5th says the same thing but the only diagnostics that you've posted recently that I found was from June 9th (https://forums.unraid.net/topic/80680-checking-for-docker-app-updates-spins-forever/?tab=comments#comment-750259) which shows that appdata is stored on cache, disk1, 2, and 3. While this is perfectly valid if you only deleted the plex folder (you did delete it didn't you?), it does *imply* that the possibility exists that the entire plex folder doesn't exist on disk3. And, according to the diagnostics on June 9th, your BIOS version is still from 2015, but numerous updates have been made to it, with the most recent being June 25, 2019. Not saying that this is the issue, but an update would at least hopefully rule that out.

Impossible to say without your diagnostics

I don't believe that there is any truth to that.

remove the -n

Jul 13 20:41:42 Tower kernel: XFS (md4): Metadata CRC error detected at xfs_sb_read_verify+0x111/0x15f [xfs], xfs_sb block 0xffffffffffffffff Jul 13 20:41:42 Tower kernel: XFS (md4): Unmount and run xfs_repair Jul 13 20:41:43 Tower kernel: XFS (md9): Metadata CRC error detected at xfs_sb_read_verify+0x111/0x15f [xfs], xfs_sb block 0xffffffffffffffff Jul 13 20:41:43 Tower kernel: XFS (md9): Unmount and run xfs_repair Run the file system checks on disks 4 and 9

Basically none. If anything, you will actually get a performance boost Because you are bypassing the fuse filesystem that combines shares stored on multiple drives into a unified directory Yes. All writes to /mnt/diskX are still protected by the parity system. Not at all. We are giving you the work around. Because the work around has been repeated over and over again. Admittedly there is a user or two who still suffer from corruption for some unknown reason when specifying directly a disk to use.

Post the diagnostics

You should chat up LSIO on discord for support for their containers and other OS's outside of unRaid.

Plex is the best example for this. LSIO: Everytime the app is restarted, it will update to the latest release from Plex Inc. (automatic) Binhex: Whenever the update get pushed upstream to whatever repository he uses, an update to the container will be released. (automatic) LT: Whenever the maintainer deems that the update is safe / stable / people are complaining will update the container and release an update. (manual) If you take plex out of the equation, then LSIO changes to be every Friday an update is released. Pros and cons to each of the above scenarios.

Yes. the emhttp process starts (in the background) via the go file, and it is what starts up all the services. But, you may need to check for network access in your startup script to ensure that the network is actually up and running (emhttp doesn't start the network, but sometimes the network being available is delayed due to multitude of reasons)