Squid

Multiple commands are needed to get the info. And it's not always 100% reliable due to how docker sometimes works, along with other overhead which is present in the docker.img file But, you're looking at docker ps -sa --format='{{.Names}}|{{.Size}}' and docker inspect --format='{{.LogPath}}' NAME_OF_CONTAINER_HERE|xargs du -b 2>/dev/null |cut -f1

Looks like issues on the cache drive, so I'll let @johnnie.black advise.

As an aside, are you running the latest version of CA? The "author" listed on each of those cards shouldn't be shyd-docker...

Try uninstalling or updating the docker folder plugin if it's installed

Not used on unRaid 6.8+ As an aside, CA supports extra custom css files /usr/local/emhttp/plugins/dynamix/styles/community.applications-nameOfTheme.css which is loaded after CA's css, so you can override anything.

It contains the VM xml's etc. If you have no VMs, then zero point in backing it up.

You've probably over provisioned the vdisk for the VM, and it's now too large to fit on the drive its sitting on

You dont need to go to the plugins tab. There is also an icon within the settings tab. I've never tried to put a direct link within the built in popup alert but will see if it's possible.

It has?!?!?!

That all being said, if you can live with the shortcomings I *could* resurrect the original plugin, but no support would be given on it.

Mover tuning and 6.9 There's a few problems with this. My original design used the existing script and simply called it appropriately based upon usage. This method will still work but, the design of the plugin itself only checked for usage on the pool named "cache". The way that the mover script works is that once it's called, all cache pools get moved appropriately. The work around for this is to modify the stock script so that another parameter can be issued which sets which cache pool to move, and only move that one. If you do the coding, LT would probably include the changes in the stock script. (No guarantees though) Then in the plugin, you'd allow multiple schedules for each given pool and call the script accordingly. The "new" plugin, also allows for movement of specific files based upon date (as I recall). This would involve a rewrite / patch of the stock script to look for the dates, but also has the same problem as the above I would think. If you do the coding via another parameter to the script, LT *may* (or may not) accept the changes. The key to any changes if you want it accepted is that the script still would have to operate identically if those extra parameters aren't specified. You would also require to have the plugin selectively choose which of the versions of the script to replace it with. Either the 6.8 one or the 6.9 one depending upon the OS version. Or, you can leave the script completely stock and forgo any of the date range options within the plugin and have it look at the pool named "cache" (or possibly another selectable pool to look at) for usage, and then the user has to accept that all pools will get moved. Because of the multiple cache pool issues, with the plugin more or less replacing the stock script, unexpected results (ie: mover not working on other pools), I'm going to mark this plugin as incompatible with 6.9 until such time as @hugenbdd decides upon the direction this plugin should take. (Or only having a single pool, but the pool isn't named "cache") mover

Post your diagnostics

Redirect the output of the command something like rclone ....... >> /tmp/user.scripts/tmpScripts/backup_shares_owncube/log.txt

It already does that

You actually have to manually remove the <TemplateURL>....</TemplateURL> field (or set it to false) by manually editing the appropriate file in /config/plugins/dockerMan/templates-user on the flash drive. The GUI has no support for any adjustments to that line

Non-issue. It's the recycle bin from Krusader

Would be for a future release of the OS

Jul 25 16:17:17 Tower shfs: fuse: unknown option(s): `-o use_ino' Delete the file /config/extra.cfg to resolve on the flash drive. This option was originally added for a 6.8 beta release IIRC, and it was subsequently removed and causes this issue.

If plugin update checks on a schedule are enabled, then whenever you go to the plugins tab a check is also made there automatically. If due to circumstances (no internet access, little bandwidth available) this process takes longer than 120 seconds then the GUI will never actually load the page.

What I'm doing is pkill -TERM -P $pid kill -9 $pid followed by ps aux | grep -i ' /usr/bin/php /tmp/user.scripts/tmpScripts/$script' | grep -v grep And kill -9 on anything returned by the above Killing off scripts is the worst part of user scripts, and something that doesn't quite seem to ever work correctly 100% (especially with long running processes spawned by the script)

Hit view results

Yeah, you cannot reach the internet at all from the server. Assuming you've already tried setting DNS addresses, I would disable piHole or pfsense if you've got them. Beyond that, not quite sure where to go. A new thread in the general support area with your diagnostics would be the next step

What's the output of ping -c 3 raw.githubusercontent.com and ping -c 3 s3.amazonaws.com Have you set up a proxy by chance for the server?

Would be helpful if you posted what message FCP is showing you.

Something else you can do, but not quite as pretty is find a server pull of a 9201-8e or 16e, and then pick up the cabling and run them back into the case via an empty expansion slot. I found a 16e a while back in Florida for $50 (genuine), and then some grabbed 8088 -> sata cables. LOL, the cabling actually cost more than the card, but have had zero problems