primeval_god

I am not exactly sure what you mean. If you are talking about the Community applications plugin the options there are just dockerman templates created and shared by the community. You can create your own templates for any container you want in unRAIDs docker tab. Templates essentially are a way of specifying all the components of the run command. You can run any image you want, local or from docker hub, just the way you would on the command line.

I really dont understand what you are doing here... This plugin should handle properly installing docker compose. To use this plugin you should ensure that you do not have compose installed on your system from any other installation method.

Docker has the commands "docker image save" and "docker image load" that would allow you to export and import an image to/from a tar file.

You need to remove the running or stopped containers belonging to each of those stacks, the orphan images dont matter. Shutting down docker/the array will not remove the containers only stop them.

I dont know for sure why this is happening but it may have something to do with 6.11 (currently i cant test against 6.11). Based on the screenshots you have though i am going to say it probably has to do with the fact that there are spaces in the folder paths of the missing stacks (well there is one without spaces but it may be shadowed by the one with the same prefix before the space). I would suggest manually removing the containers for the missing stacks (with dockerman) then in the terminal rename the problem stack folders with '_' instead of spaces and then try refreshing the page (or maybe rebooting).

First and foremost I would remove the compose manager plugin and whatever you previously used to install compose then restart your server to make sure not traces of compose are left. Then try re-installing the compose manager plugin. How were you installing compose previously by the way? And what version of unRAID are you running?

This is normal behavior. Update status tracking only works for containers created by Dockerman. For containers created by other means including compose manager the update status is not meaningful.

I have always been a big advocate of this stance, and doing as much in docker as possible. That said these plugins do provide a few essentials that i would argue should be part of the base system but are not (iotop, screen, tmux, powertop). And gives us the ability to update some minor things out of band with the base os releases.

I think i may see the issue. Rather than specifying container-name:my_port just specify container-name to the application, it looks like it will add the default port number on its own. When working with containers that communicate on an internal network there is not need to use port mapping (-p option on cli or the port field in dockerman templates). When communicating via the same custom docker network containers have access to all of each others ports. Port mappings are just for making ports accessible externally on the docker host.

I am not certain i understand the question. It sounds like you are trying to allow one container to talk to another using the container name as a hostname. If so you will need to have both containers on the same custom bridge network, the default bridge network will not work as it does not support using container names as internal hostnames. If they are on the same custom bridge network then the specifying container-name:port in the setting of one containers application should allow you to reach another (no need to make a port mapping in this case either so long as the port is only for internal communication).

To an extent you do. What you dont have is the ability to use parity data to recover a file corruption found by BTRFS or use filesystem checksums to determine where a parity invalidation is located (par1, par2, or a data drive). Personally i have no more interest in SnapRAID than i do ZFS, or a pure BTRFS solution. I am very happy with unRAID (the disk pooling system not the OS, though i am also happy with the OS) and would not trade any of its great features like realtime parity, and independent disk file systems for any other solution. That said bitrot resistance (whether it addresses a realistic problem or not) would be the cherry on top, and the underlying data to make it happen is already there just waiting for someone more clever than myself to figure out how to reach across the layers of the storage stack and bring it together.

Combining BTRFS integrity checking with the unRAID parity system is a feature i have long wished for, but I am well aware of how dauntingly complex the implementation would be. That said seeing this brought up again and your comment specifically made me wonder how much of a hurdle that first part is. After some digging I think there may be ioctls for that functionality, GETFSMAP for XFS and maybe BTRFS_IOC_LOGICAL_INO for BTRFS. Its only the first of many hurdles but I have spent enough time down this particular rabbit hole for today.

Despite what this article implies the debate about what bitrot is and how much of a threat it poses is by no means settled. If you search this forum you will find well informed arguments on either side. For my money i will take an unRAID array over zfs any day of the week. In the end though the most important point to make is that RAID is not backup, checksums are not backup, snapshotting is not backup (well technically its a kind of back up but thats part of a much larger discussion), backup requires having a copy of data on an independent media (i.e. a copy on something/somewhere else that is likely to survive destruction of the original).

Interesting, so this isnt going to play nice with the Compose Manager plugin without some modification. The problem is likely that Compose Manager assumes all .yml files in its directories to be compose files. I would suggest the following changes. Create a folder for diaspora under appdata and place the database.yml and diaspora.yml there. Create a new stack with compose manager and copy the contents of the docker-compose.yml into the compose file. Modify ./diaspora.yml and ./database.yml with the path to those files in appdata. Create subfolders in the appdata folder for each of the volumes listed in the docker file. Remove the volumes section at the bottom of the compose file and replace all volume references in the file with the associated appdata path.

The webui portion of this plugin is designed only to show compose stacks created and launched via the webui. I think your issue specifically is that you are launching the stack differently than the plugin does. The plugin uses something like docker compose up -f docker.compose.yml -f <possibly other compose files> -p <projectname> Where project name is a sanitized version of the stack name assigned in the webui. The project name is what the plugin uses to match against and display the status of stacks.

@hasown@NAS A new version is available with an updated version of compose.

Reason: I would prefer to restrict access to the unRAID webUI to only one of my Ethernet adapters and use ports 80 and 443 on the other adapters for hosting docker applications. Previously i was using the hidden BIND_MGT setting to restrict the WebUI to eth0. However it appears that functionality has been removed in 6.10 per the latest in the discussion here I would like to request a new mechanism, preferably not hidden this time, to support this use case.

So just to clarify are you saying this is a bug or that the ability to bind the webui to a single IP address with this mechanism is no longer a feature?

Yeah its been a while since i updated the opening post (not sure many people read it anyway). If there are any security issues or important bug fixes in the packages i include feel free to bring them to my attention and i will try to patch them asap. Otherwise the answer is probably sporadically or when i remember to check my dependencies. For this last release I forgot, I will try to get an update out soon.

A new version of the plugin is available. This version allows choosing alternate project directories for storing more complex docker stacks. This version also implements functionality for managing webui and icon labels for unRAID webui integration.

What directory is it writing the tmp files to? Not sure if it is the correct way to fix it but you can mount a tmpfs directory to your container so that the files are not written into the docker filesystem. In the extra parameters section you can add something like --mount type=tmpfs,destination=/tmp

With that you should be able to identify which container is growing in size. From there its a matter of determining why the application in the container is writing data to a directory inside the container rather than a bind-mounted host directory.

Run the following command in your terminal. docker ps --size It should list all of your containers along with their size (both the read only image size and the writeable layer size). See https://docs.docker.com/engine/reference/commandline/ps/ for specifics.

I dont really know all that much about macvlan networks but this sounds like the same issue as @Kilrah has.