Squid

if you're having problems with the script, the one thing is that you've got spaces within that path that shouldn't be there It should be #!/bin/bash echo running powerdown /usr/local/sbin/powerdown

Your recurring problems appear to be cabling. SATA connections (for a lack of a better word) are pieces of shit (this is the non-IT term). Reseat the cabling and/or replace the cables, ideally with NON locking cables (WD a couple of years ago made some changes to the shroud on the drives to better work with hot swap bays with the result that a ton of locking cables wouldn't work properly if they didn't have the internal "bump" on the connector.

Technically OCD since the net result is the same, but the -p stuff you're adding into extra parameters doesn't really belong there, and should instead be done via adding a port to the template.

As an aside, this test is going to be removed from FCP as I don't believe that it's strictly necessary anymore except for some very specific use cases, and in certain cases actually has the opposite effect

Works properly on Chrome though. (And also on Firefox / Brave for me)

Yeah, not a problem. Had already made the change, but never released it, as someone else brought it up somewhere but I couldn't replicate it on any page.

You're not going to be able to start the array due to Apr 23 23:45:52 AnimeKing emhttpd: cmdStart: too many devices On a plus key with 13 devices Best guess why the UI won't load though is because of Apr 23 23:45:56 AnimeKing root: Starting unraid-api in "production" mode. Apr 23 23:45:56 AnimeKing root: Value "invalid" is not no/yes. Apr 23 23:45:58 AnimeKing root: API has been running for 2.1s and is in "production" mode! Restart in safe mode and see if that fixes it up.

At the same time did you rename the pools or remove the cache pool? You have no "cache" pool, but appdata backup was set up to backup from the cache pool to the array. When you restored it, it dutifully put the backup exactly where it was told to, except that the cache pool doesn't exist, so it winds up in RAM Additionally, since this is what presumably happened, you also have docker containers that were referencing /mnt/cache/appdata/..., so the system is going to automatically create /mnt/cache every time the container starts.

https://forums.unraid.net/topic/48707-additional-scripts-for-userscripts-plugin/#comment-481688

Not the real expert on this, but you're currently connected to eth4. Try moving the cabling to eth0

You're probably going to have to bite the bullet and hard reset the system. Also would be a good idea to run a pass or 2 of memtest

Your keyfile for the encryption is missing, so the array can't start Apr 23 08:58:02 BGDunRAID emhttpd: Missing encryption key Also wouldn't be a bad idea to update to 6.9.2

Start by posting your diagnostics here

The only way for a "true" backup is to ensure that there are no possible changes to files while the backup is taking place (eg: File A & B get changes, but the previous version of A made it into the backup set, but the new version of B did). Stopping the containers ensures that both A & B are in sync with each other. In practice though it's not a real problem.

There's lots of apps for Windows that'll do that for you (just google it), and then run the program against the particular share.

You'll see in the syslog when it does a backup the order that it's stopping the containers. The order it restarts them is identical (and shouldn't change afaik from one backup to the next) Because of this, any container that requires DelugeVPN to be running (--network=DelugeVPN) will fail to start (and orphan) if it starts before Deluge. The plugin at this point in time does not respect the startup order dictated in the docker Tab (top to bottom). Your best solution is to set in the Advanced Settings of the backup for Deluge to not stop. (or alternatively all of them)

What is 192.168.77.1 your router or a pfSense box? It's just an odd IP for a router, although there's nothing wrong with that.

The real question is why are they becoming orphans? Are the containers dependent upon each other (ie: does something like nzbget run through a vpn from another container)

It's normal, and can be replicated on every OS out there. Here's how this works. The OS (in this case Windows) attempts to do a rename. This fails (because your cannot rename from \\media\,,, to \\downloads\... the same way that you cannot rename from C:\... to D:\...), so it has to do a copy / delete operation. MC operates below the system, and because of that it does succeed in the renaming, so it's instantaneous. To work around this what you need to do is set up a "root share" (space invader one has a video about that). Then the mount points are the same and you're renaming instead of copying / deleting, because you're going from \\rootshare\media to \\rootshare\downloads) There are some caveats with that however. If you did have include / exclude disks or use cache settings different between the two shares, then the renamed file may wind up on the wrong disk (it'll actually stay on the source disk) in apparent violation of the rules, but it's actually not a violation because you're bypassing the system

First, you should update to 6.9.2 If it still happens, then delete smart-one.cfg from /config on the flash drive, reboot and set things back up if necessary

Did you try what the message is suggesting to try? post your diagnostics

If it's showing Tower Login and the wall of text is still there, then you booted normally, and not via the GUI mode. GUI mode is an option from the webGUI over the network login with root and your password and then enter in diagnostics If you can reach your shares over the network, then grab the diagnostics file that's saved on the flash share in the logs folder and post it here If not, then powerdown pull the flash toss it into another system and post it here

No unless you've copied them there, or messed up a command or something. .cache, .local, .screen, mdcmd are probably remnants of whatever you did.

It's 192.168.50.2 that you're assigning it that's in use by something else, in this case presumably your server since that's the SERVERIP variable you've done. If you're running on br0, you need to assign it a unique address (and keep ServerIP pointed at your server)

Then USB backup portion of the plugin isn't enabled. No biggie. If you use unraid.net to keep backups, the super.dat file is included in it