primeval_god

The containers from any stack that was running will still exist when docker is restarted but will be in the stopped state. For those stacks that are not set to autostart the the containers will stay stopped and the red square is the expected symbol to mark this condition. As for your stacks that are set to autostart, due to the other issue you have, the containers fail to start when compose up is run, leaving the containers in the stopped state and the red square displayed. Please clarify this statement. From your previous posts i was under the impression that clicking "Compose Up" would not result in the stack starting. My understanding was that you first had to click "Compose Down" then "Compose Up", which in effect removes and recreates the entire stack. The commands executed by auto-start and the compose up button are the same. My suggestion would be to move the VMs and other containers on to the custom created networks as well. Once created they will be available for use in the rest of the unRAID GUI. Essentially just replace all the unRAID created networks with a manually created equivalent.

The compose stacks without autostart do not 'fail' they are working as intended. The Red Stop Icon indicates that the compose stack is stopped, i.e. its containers exist but none of them are running. This is expected behavior for a running stack with autostart off when docker restarts. It is the same behavior as for non-compose containers on unRAID that are not configured with autostart. As for your compose stacks that are set to auto start, the problem and recommendation remain the same as last time it was brought up. Compose stacks do not seem to work with the docker networks created by unRAID (via the gui). It appears that those networks are removed and recreated by unRAID when docker is restarted. Compose does not like this as it references networks not by name but by id in its internal live state. The solution is to not use those networks with compose stacks, instead you need to create custom macvlan networks manually on the command line using a docker network command. Once done the "Preserve user defined networks" setting will ensure that the custom networks are not removed between docker restarts. Compose containers should start correctly when attached to those networks. As for why non-compose containers work fine with the networks unRAID creates, I dont really know. I assume it has something to do with how dockerman works, though it could just be something compose is picky about.

The easiest solution would be to not use the unRAID provided brX custom networks as they are not persistent. Better to ensure "Preserve User Defined Networks" is true and then create your own custom networks with docker network create.

A docker volume is persistent storage managed by docker that is mounted into a container's file system. The lifecycle of a volume is independent (generally speaking) of the container to which it is attached. So even when you remove a container its volumes may stick around. In your case I believe that the immich_postgres container is using a named volume which gets re-attached to the container every time you create it. In unRAID we typically dont use docker volumes and instead bind mount host directories (typically under the appdata share) into containers for persistent storage instead. It is typically easier to grasp and manage than docker volumes for those unfamiliar with them. It is also the way dockerman (unRAID's docker manager) does things.

Looks like the database is stored in a docker volume (something that is not really best practice to use in unraid). The command "docker volume ls" should list the volumes on your system. According to the compose file the one with the postgres database is called pgdata, not sure it if will be named the same when listed on the command line. An alternative for finding it is to bring up the compose stack and then run a "docker inspect immich_postgres" and look for the volume section. Once you know the name of the volume you can bring the compose stack down and then run "docker volume rm <volume_name>" which should remove the volume.

I use Bender

See https://docs.unraid.net/unraid-os/manual/users Its really not overkill, its the way the system is meant to be used (in unRAID that is). Containerization really doesnt have that much overhead in terms of cpu and memory usage. Its just tooling over cgroups and namespaces after all. In fact systems exist where every normal linux process is containerized (see Rancher OS) and they manage to stay performant. Admittedly the there is a bit more overhead in terms of disk usage especially with docker. And there is something to be said for the increase in complexity for those less familiar with docker and LXC, however the unRAID webui experience (and LXC plugin experience) help a lot in this area.

Also worth noting that the special sauce of unraid isnt really doing the parity in real time, that is what the linux md subsystem does normally. The special unRaid part is dedicated parity disks for raid 5 and 6 (rather than the more common distributed raid 5 and 6) and the lack of block level striping so that each disk has an independent file system.

Not that there is anything wrong with using a plugin like LXC. But the tone of this discussion made me think that built-in options might be preferred.

This is unRAID, it does not use linux users for permissions. The ONLY user in the convention linux sense is root. Ideally you should not have other systems SSH directly into unRAID. The better way to handle it would be with a docker container or VM running an SSH server and having access to the specific array folders required. Personally I use an LXC container for this, but that requires the LXC plugin rather than built in functionality.

What setting do you have for swappiness? Lower values will swap data out less aggressively.

Actually, something i just noticed, your swapfile size is set to 10 MB not GB. Couple of things for you to try if you would. Could you verify that the fields for location, filename, and swap name contain no extra whitespace at the end? Additionally please re-specify your swapfile size using only digits (no . or , etc).

Other than taking up disk space none that I am aware of. The plugin has been known to struggle to format large swapfiles, basically the gui hangs or the operation fails waiting for swapfile creation to complete. I dont think thats your case though as the swapon command seems to show a functioning swapfile. Also did you say what version of unRAID you are running?

So far as the setting of this plugin are concerned the swap file size is the total amount of swap available to the system. I dont consider myself an expert on swap in linux. The amount of swap you need is less about your total amount of ram an more about your ram usage. In general you would want to keep your swap usage low. I wouldnt think you would need more than a few GB of swapspace. 2G-4G maybe?

That would seem to indicate that the swapfile is active. On the command line you can run 'swapon -s' to confirm. Weird the that webpage does not update.

What does the system log say?

The swapfile cannot be placed in the root directory of a cache drive on BTRFS. It must be placed in a subvolume. Best to specify a directory that does not already exist and allow the plugin to create the subvolume itself. I would suggest something like '/mnt/cache/system/swap/' Click the little help icon next to the location for further information on swapfile placement. I would also recommend setting swappiness to something lower than 10 (i use 1) and setting 'start swapfile during array mount' to true. Finally you will need to click the start button to start the swapfile for the first time.

If you are not familiar with swap you should do some googling to better understand computer memory systems (linux specifically). The basic idea though is that the OS can take the least recently used memory pages and move them from RAM into a file on a disk (the swapfile) in order to free up RAM. When the pages stored in the file are needed they get moved back into RAM and something else gets swapped out to disk. The downside of this is that swapping data out to disk has a significant performance penalty. That is typically not a big deal for normal swap usage where swap contains rarely used data and you are mainly protecting against an app occasional using a ton of memory for a short time. Swap is not a good substituted for additional RAM on a system that is consistently memory constrained however. Yes it would, how well it performs however depends on exactly why you are running out of memory. If Jorge thinks it could help though its definitely worth a try. There is not really any risk to using this plugin that i can think of. You will need an xfs or btrfs formatted cache drive (preferably sdd) in your system to host the swap file.

unRAID is primarily targeted as a home NAS appliance OS. Off premise usage is not really the target audience.

If you are using docker compose there is no way currently to disable the update ready text.

So in this case dockernet is created by the compose stack when you do compose up. I dont see anything wrong with the network configuration. Though i am a bit confused as i thought the issue was with containers not starting because they were referencing non-persistent external networks (networks created outside of the stack file). For reference the configuration for an external network would look something like this where frontend is an external network created on the CLI and backend is created by the stack.

This is correct. The plugin does not provide any integration with the unRAID dashboard, you can view swap usage in the swap plugin settings menu if need be.

Depending on what the script needs access to the proper way to do python in unraid is to run it in a docker container. You can either create a custom image with all of your python files included (better if you need to install a bunch of packages link) or use a default container and bind mount in the script directory. The second option might look something like this docker run --rm -it -v /host/scripts:/container/scripts -w /container/scripts python:3.10 python main.py -some-arg

The general recommendation for unRAID is that anything that can be done in docker should be done in docker. Plugins and packages are choice number 3 (after VMs) for things that must interact with the unRAID OS/Webgui directly. As for why non-docker options exist for dockerizable things; plugins are community maintained and not everyone in the community likes to follow recommended practices (and some have advanced usages in mind that are harder to fit into the recommended ways). That said personally the "just put it in a docker" option has served me well for many unRAID services.