Squid

Why aren't you isolating the GPU you're passing through to the VM?

One of the upshots of docker is that the rest of the files on your server that you have are only visible to any given app if YOU give the app permission to them. @binhex, any thoughts?

That's a weird path to begin with. Either it's on a cache-pool named borg-repository, or it's in RAM because UD always mounts to /mnt/disks/... rm -rf /mnt/borg-repository/WDC_6TB_BACKUP_DRIVE/Borg/config will get rid of it. Reason why New Permissions won't get rid of it is because it's presumably in RAM and isn't an actual share. Only shares are run through on the New Perms script

Have you already had it installed previously? I just installed it and as part of it's setup its asking me for a user name and password

@JorgeB

If this does actually continue, can I suggest that you install NetData. With it (scroll down to sensors), you'll be able to see a graph of the temps over time that the drive is reporting. Default display is last 5 minutes, but at the top you can switch it to 12 hours

The webUi always refers to the container port and really shouldn’t ever need to be touched. All you have to do is change the appropriate host port on the template and it figures it all out. Also, if you running the container in either host network or assigned it a specific up address then all port mappings are ignored by design of docker itself

Or apps, previous apps. Check off what you want gone then hit delete

Shouldn't be an issue so long as you reference the server's IP (host or bridge network mode) - 192.x and not the container's internal IP (172.x)

The "slave" mode test was removed for a while because it seemed that it was no longer necessary. However with recent changes to UD it has now become necessary again for a trouble free experience so it was re-introduced.

What error (if any) are you seeing when attempting to access? I assuming you're attempting to access the files by going to \\tower (or \\tower.local) Can you do it via \\192.168.20.101 (or at \\192.168.122.1)

You need to forward the port on the router. Although I'd personally be hesitant forwarding 3306 to 3306 as that port is probably going to be subject to a lot of automated hack attempts.

Disable autostart on all containers in Docker, reboot. Process will odds on be gone Then start up the containers one at a time and see when it starts showing back up again.

The writeable column is extra files the container has written within itself. ie: In your case it would appear that tdarr is storing intermediate / temporary files within the container. If this number continues to grow (or grow significantly), then hopefully there's some setting within it (or the template) that will map those temporary files outside of the container to appdata where it belongs

The txz's (installation files) for the various plugins are not saved on the backup. This is because at boot time if the applicable txz for the plugin is not present it get's automatically re-downloaded. Also, any empty folders (or folders only containing other folders and not any actual files) are not part of the backup. The previous version of the OS is also not restored onto the flash, along with any generated diagnostics that happened during an unclean shutdown (ie: the logs folder)

I chmod 0777 the destinations for easy access via SMB. Source I don't touch. Mine don't change: Here's my before and after. The first root:root after andrew:users is a new directory I created, and it didn't change either modify time or permissions. Are you referencing that test directory in a container anywhere?

I'm definitely not a SQL guy (always used MariaDB for whatever has required a SQL db in the past), but I find it interesting that even on the sample installation method listed on the registry for MySQL docker run --name some-mysql -e MYSQL_ROOT_PASSWORD=my-secret-pw -d mysql:tag The same error results.

With the templates, it should be best to leave them at the defaults as the maintainers would have already set the appropriate values accordingly. IE: set them to be nobody Unraid doesn't have "users" in the normal Linux way. The huge value in docker containers is that they don't have permissions to anything anywhere on your array unless you've explicitly granted them access to it (via the path mappings and whether or not its read-only or read/write). The PUID / PGID and UMASK basically set the permissions of the files that it writes to the array (if it does) to something that's compatible with Unraid's implementation of user shares.

nvme drives all run hot 42C is nothing to them. Samsung drives for instance are rated to run up to 70C You're running ECC memory. Does your system event log in the BIOS say anything? You should actually be running a standalone boot stick with memtest from https://www.memtest86.com/ as the one included won't catch any ECC errors that happen unless it's completely uncorrectable (due to licencing issues)

The OS itself has no limitations or anything if only running on a single drive. There's been multiple people (from reading the threads here) that have installed the OS on a NUC for instance.

What are those folders? The source or the destination? Destination permissions are irrelevant

Overhead is overhead and varies according to the size of the drive (and as you've seen file system chosen). What's the actual percentage of used space? While your use case may be different, that 27GB to me (not that I've ever looked on a blank drive) would amount to my local coffee shop raising their price by a penny. Or as a friend of mine once put it: it doesn't matter if you've got $0 or $20 in your pocket - you're still broke, and a drive that get's filled up > 95% isn't going to wind up being very efficient at storing the last 5% files on any system.

(And it also never hurts to run a memtest for a couple of passes... Most people always assume memory is good)

Complain to hoobs themselves. They are the ones who maintain the container itself (ie: the version in CA is the official version) and they last updated it 10 months ago.

Any changes you make to the system that aren't within /mnt/user or /var/lib/docker are not persistent and will have to be reapplied on the next boot. Utilize the user scripts plugin to accomplish this.