Squid

If using slave causes problems, then ignore the error. Nothing in FCP is definitive.

Fixed Also on today's update, a new warning will be issued under 2 circumstances: The string xmrig is found in your go file, or a process named xmrig is running. If it's found in your go file, then most likely your entire system has been compromised and a hacker has edited your go file to automatically install xmrig on every boot If it's a process, two scenarios exist You're purposely running it. In which case this warning is safe to ignore You've possibly installed a compromised container via a random dockerHub search that is masking the fact that it's installing xmrig as it's primary purpose. For reference, xmrig is mining software, and since malware, viruses, ransomware etc are now passe, Compromising a system to instead mine for bitcoin is the hack of choice.

What's the problem you're having?

Now supports Azure / Gray themes

Post your diagnostics

Post your diagnostics

Never meant to imply to it was a bug, as I know it's not as per my first response.

Updated it to use a monospaced font. Makes sense.

As an aside, CA looks for hard-coded paths (to pools or disk shares) and automatically adjusts the templates to suit the user's system (so that it doesn't cause issues like this)

Honestly, I disagree @bonienl Not saying that having it auto generate isn't a bad thing. Just saying that it should generate it on the Edit Template Screen if there's no description in the system and not update the actual Description entry until the user actually enters something in there. Net result is the same, but it keeps it up to date with the Container Path if no description is present, but still allows a description to override everything.

Without the diagnostics, assuming that it's very early in the boot process when it's initializing the cores, it's not a problem and safe to ignore.

I know what you're saying, and I'll look at the coding on the weekend. What the system should do is not by default populate the description ever unless the user / maintainer does it themselves, but on the edit template screen show the container path if there's no description present.

No. You've given it a Name of Mnt The description is what you're seeing that's not being updated. If no description is present, then the system populates the description after saving with the container path. If the description already exists, then the system does not update it. You see this on many good templates where the author goes to the extra step and tells you what the path is actually for, not simply "Container Path: xxx"

docker itself automatically creates every host path, and probably not much the devs can do about it. But, since /mnt/user0 now exists all the time regardless if a cache pool is present or not, maybe mover can check if the pool is present before moving anything to it. (Although thinking about it, I can see some interesting use cases for not having a defined cache-pool but having the extra mount point within /mnt)

You'd have to post your diagnostics (and probably post in the MyServers announcement thread)

Kinda vague what actually happened.

$caPaths['application-feed'] = "https://raw.githubusercontent.com/Squidly271/AppFeed/master/applicationFeed.json"; $caPaths['application-feed-last-updated'] = "https://raw.githubusercontent.com/Squidly271/AppFeed/master/applicationFeed-lastUpdated.json"; $caPaths['application-feedBackup'] = "https://s3.amazonaws.com/dnld.lime-technology.com/appfeed/master/applicationFeed.json"; $caPaths['application-feed-last-updatedBackup'] = "https://s3.amazonaws.com/dnld.lime-technology.com/appfeed/master/applicationFeed-lastUpdated.json";

GitHub with a backup alternative on AmazonAWS (via Limetech). Automatically tries both before returning the error

The "Container Path: /mnt" line actually bears absolutely no relationship at all to either the container path (or the host path). It's rather the description you've given it. In absence of a description being given when adding a new path, it uses the container path. But, when editing an existing path the description already does exist and the system keeps the description (But you can edit it all day long)

You can also try one of the ACS override options to try and break apart the IOMMU groups As an aside, you *may* have problems with using the Marvel controller on your drives.

If you used rm -rf /mnt/homebase Then only that folder would be gone. You probably did something like rm -rf /mnt But it wouldn't hurt to post your diagnostics. At this point, you best recovery option is to pull the drives, attach them to a Windows box and try out UFS Explorer to recover the data. (It has a free option that let's you see what to recover, but the full version runs something like $80

And make sure that all of your plugins are up to date.

And make sure that all of your plugins are up to date.

Here's how the system handles path mappings. On any given app, if there is a container path of /config, it doesn't matter what the template author puts into it as a host path by default. Unraid will always override the host path with whatever the setting is for default appdata path (Settings - Docker) and append the name of the app after it. On any given app, if there are any paths pre-populated (other than /config) in the template, CA will automatically adjust them IF they directly refer to an array drive or a cache pool. It looks at the user's system, and if the template says "/mnt/cache/data" and there is no pool named "cache", it will change the path to be the next available cache pool (alphabetically). If the user has no cache pool at all, then it will change the path to be /mnt/disk1/data (assuming there is a disk 1, otherwise it will change it to disk 2 etc) These changes only happen when installing a new template and are the default settings. If you're editing an existing app, then you can override the settings for /config all day long. (Or override the paths when installing a new app - these are the default paths the system offers up to the user.) As an aside, technically on 6.9+ there should be zero reason to ever still have to use /mnt/cache/appdata/... instead of /mnt/user/appdata/... If the appdata share only exists on the cache-pool, the OS dereferences /mnt/user internally to instead be /mnt/cache/... But, like everything else IF there are still problems with /mnt/user/appdata with certain applications, let Tom know.

That's the one