Squid

You've got emhttp running twice in the go file. #!/bin/bash # Start the Management Utility /usr/local/sbin/emhttp & /usr/local/sbin/emhttp & . . . Does it work if you remove one of those lines?

As previously mentioned, Not True. Simply no more updates for CA running on 6.11 FWIW, Pretty much any version of CA which is currently running on the applicable OS version of Unraid (including going back to CA running on Unraid 6.0) does still work no problems. And, FWIW my decision to drop 6.11 support came before I knew about the licensing changes. It wouldn't have really mattered either way on dropping support though.

Oh, and FWIW veto files slows everything down.

From Finder, you have to first navigate to the TM share in order for TM to see it. IE: The Mac has to have it mounted first. After adding it in, TM will automatically mount it. NOTE: I don't recommend having TM shares moving to/from the array or cache. IF something happens in the middle of the move and everything doesn't get moved for one reason or another, the backups get trashed. Leave it on the cache pool or write directly to the array. Also, TM shares moving from cache to array (and vice versa) has not been fully tested under all circumstances to begin with.

Highly unlikely its CA. But if it ever happens again, delete /config/plugins/community.applications/community.applications.cfg from the flash drive and then try another page without rebooting or deleting anything else will tell you if it was CA itself

Sure. No argument per se on that one. But, the point of this patch was to remove the support requests from how the docker executable handled things since 2015 vs today, and based upon at least one person who surprised me by getting caught by it is likely a widespread configuration mistake. And the effects of what docker changed also happens on an update resulting in an orphaned container. Or to put it another way, the point of the patch isn't to make the user's life easier, but rather everyone else who has to continually answer the posts about this that will go on and on and on. The user's life being easier is simply a nice side effect... Did 6.12.6 not fail when the template referenced a non-existent device (eg: /dev/dri15?)

All future releases of the OS have the same code patch included

Docker image is empty, so easiest thing to try first is Apps, Previous Apps. Check off everything you had before and hit install. VMs I'll let someone else better suited to assist with that.

No. ANY path that would look akin to this It's empty. Seems like a lot of users have left paths (which were unused by them) blank instead of hitting "Remove" <6.12.8 docker itself ignored it. 6.12.8+ Docker returns an error (IMO rightfully so). Trouble is that if you've done that without this patch on 6.12.8 when you simply update the container it will return an error, become an orphan, and require a reinstall from Apps, Previous Apps and you to find the empty path and remove it. I figured the patch would save everyone a ton of hair by ignoring empty paths when the docker run command gets created. As said, it's not a bug in the OS. I'm just making things work the way they used to for this one thing. I figured that if one of the LT devs winds up asking me WTF happened here (and some users before the patch), it would wind up becoming a nightmare and a one line change solves it.

Per @hotio, this thread has been locked. All support requests / help to be handled on Hotio's Discord server (click the app, then select "Discord"

Done. As soon as I get maintainers to adjust the templates it'll show in CA as a new Category

This has nothing to do with anything. As a matter of point, the installation URL for CA to run on 6.11.x is publicly posted in the CA thread (and is also a recommended post), and all of the downloaded data files remain fully compatible with that version. No further updates to CA running on 6.11.5 which is pretty much the same as no further updates to 6.11.5 will happen since 6.12.0 was released. There came a time when a major overhaul of CA dictated the either I spend forever debugging all of the necessary compatibility for an OS version which had already been supplanted. I chose to drop compatibility going forward, but make damn sure that all 6.11 users weren't out of luck. Similar thing happened when I've previously dropped compatibility for everything pre 6.1, everything pre 6.5, everything pre 6.9 on various releases of CA. If I had to maintain compatibility today with 6.0.0 then trust me CA would not be anything like what you're seeing on 6.11.x I don't drop compatibility for no reason. It only gets dropped when the gain isn't worth the pain

No. There was a period of about half hour yesterday when every plugin got tagged that way

Yes. But there's no syslog detailing what is going on as it tries to connect. No versions of the driver. No hardware IDs etc etc etc. Diagnostics are what show everything necessary.

That's a normal message with every installation.

If it's not there you're not running 6.12.8

Diagnostics would help better

try rebooting the mac? using all lower case on username?

Diagnostics would always help. Rosewill bays while they do work (I have 24 bays total), they can at times be flakely and always require that little extra push after they are locked in place

.8 won't really affect anything other than TM. Is the password super complex or something? Try simplifying

This is the user you're trying? valid users = n...5 Also, for absolute best Mac (especially with TM shares) you should be on 6.12.8+

Diagnostics might help

The pics you've posted are broken links. And also what OS version are you on?

Just pointed out to me. Working it

Keeping. Doesn't affect anything