primeval_god

This thread is for questions about the composeman plugin itself rather than specific compose stacks. As this is pulled from github, (not the envisioned use case of this plugin) I might hazard a guess that some of the file permissions are incorrect as unraid doesn't really have users other than root. How that interplay with permissions withing the container environment I dont know.

Now that ZFS support is wrapping up I would love to see some focus return to the star feature of UNRAID, the unRAID array. First and foremost I would like to see formalization of the array as just a type of pool concept, both in documentation and nomenclature in the GUI. Having to explain the difference between the array and other pool types gets old after a while. It would also be cool to see the unRAID type pool be augmented with some more advanced features. It would be really nice to be able to replace or re-add a failed device (or expand the pool) without having to take it offline (hardware permitting of course). Adding an option for a read cache would be really cool, either a write-through block cache or some way to intelligently promote files to some sort of read-only overlayfs. My biggest wish would be to see some attention given to the file integrity properties of the unRAID type pool. Things like ensuring that fs read errors are properly propagated through fuse layers and samba (pretty sure there was an issue raised about this at some point). The biggest longshot, but coolest feature would be to see the BTRFS check summing feature (and ZFS I guess) integrated with parity checking similar to what Synology hybrid raid achieves.

Not sure what you mean here? Your app does appear to be available via community applications.

What you are all seeing is a known issue with the way Dockerman displays networks for containers created via compose. There is an open PR for the unRAID webui to fix the issue but as of yet it is unmerged. https://github.com/unraid/webgui/pull/1616 Aside from patching the webui there is no convenient way to fix this.

If it doesnt change when you change the text of the label then its because the webui is using a cached version as described elsewhere in this thread. You can use the "docker inspect" command in a shell to see what the contents of the net.unraid.docker.webui label are. That string is exactly what unRAID Dockerman sees, how it process it and if it caches it are in part of unRAIDs code.

Actually I think the fix for 1 & 2 is this https://github.com/unraid/webgui/pull/1616

The compose plugin is intended for running simple compose stacks created via its webui not arbitrary compose stacks pulled from github. I dont know off hand how multiple additional compose files in the stack root directory would effect the commands used to start and stop stacks.

Doesnt 'Uptime Kuma' automatically gather all the info it needs for docker containers? The only setup I see listed on its "How to Monitor Docker Containers" page is instructions on how to give the container access to the docker socket.

I use releases for the compose plugin and the swapfile plugin.

How so? It looks to me like one of the links in your initial post shows how to build a knockd container based on alpine without any compilation. I understand the hassle of staying up to date with the latest system admin stuff, but in unRAID docker by and large is the most plug'N'play solution. Installing packages directly in the host os is considered the deep-level system administration solution and is generally not the recommended path. Containers can be smaller than that depending on the base image and included application but a 100MB container is pretty reasonable. The general idea is to isolate user programs from the unRAID host os. Knockd is pretty low level though so depending on what your doing with it containerizing might not be a good. Speaking of which if the idea is to use knockd to make the unRAID webui or ssh server available remotely, dont. The unRAID host os should never be exposed directly to the internet. A VPN is a much better solution.

The "Update Stack" button in the composeman ui will run the command "docker compose up -d ---build". As for the specifics of what that will do it depends on what the build sections of your compose file look like and what Docker files they point at.

The plugin only automatically creates hashes for new files. For initial setup you need to manually trigger hashing for existing files. To do this you need to go the the control page under the unRAID "Tools" page and use the "Build" button. Dont forget you can enable the help text in the webui to get more information. p.s. read back in this thread a ways for info about nfo files.

This is not really a question about this plugin. The compose file spec allows you to specify the container name with the "container_name" key.

This is not correct. If a device in the "unRAID array" fails and you have enough redundancy to rebuild it then there will be no loss of access as the disk can be emulated using parity and the data from the other disks in the array. There is a performance penalty in accessing data from an "emulated" disk, as well as a penalty when accessing the array in general while a rebuild is happening (when you are replacing a disk). This is pretty the same way that a traditional RAID system works. The real advantage of the unRAID array type is what happens if you lose more drives than you have redundancy. In the case of a traditional RAID system if you lose more devices than your redundancy you lose the entire array. For an unRAID array since each disk (except for parity) has a stand alone file system you only lose the data on the disks that have failed. Any functional data drives can be removed and mounted as a normal linux file system.

My understanding was that at some point the "array" terminology would be replaced with something like "unRAID pool". So the options for disk pool types would be xfs (single disk but still referred to as a pool), BTRFS (1 or more disks using BTRFS raid levels), ZFS (1 or more disks using ZFS raid levels), unRAID (1 or more disks, mixed files systems, using Limetech's proprietary RAID like redundancy). My hope would be that Limetech updates the terminology coincident with whatever release removes the requirement for having at least one disk in the unRAID pool. p.s. What is a "ZFS hybrid" pool, i am not familiar with the term, or zfs in general.

This can be a point of confusion for many new users. The term Array will hopefully soon be a legacy term (the term not the functionality). The term "Array" refers to the currently singular, currently required pool that uses the proprietary unRAID redundancy scheme. Here is a more in depth post I made to try to explain the concept a while back

The only correct way of using this plugin is to create a stack through the ui.

If you created the stack using the UI then you will still need to pull the git repo to get the dockerfile in order to build the project. As mentioned this is venturing beyond the supported functionality of this plugin. That said if you cloned the repo into another folder say `/user/mnt/appdata/path_a/build` and then change the line `build: .` to `build: user/mnt/appdata/path_a/build` that might solve your issue.

Just ignore the "update ready" text for containers created via compose, they are not correct. The update tracking feature of the webui does not apply to containers not created via the webui. If you believe there is an update available for a container created with the compose plugin, there is an update stack button on the compose page you can click.

Its a cool idea, but unlikely to be helpful except for the rare case of actual bitrot. For things like overwrite, accidental deletion, corruption due to software error, etc. the parity drive will be of little to no help because unRAID maintains real-time parity. Any changes made to the file under normal operation are immediately reflected in parity.

There are no plans to support compose stacks other than those created through the webui. The default location for stacks created via this plugin is on the flash drive. That default can be changed via the settings screen, or when creating a new stack there is an option to specify where it should be created. This plugin provides a webui for people to create and manage simple compose stacks on unRAID. It exists primarily because unRAID's Dockerman lacks easy support for multi-container applications. It is not meant to be a full fledged, all features included compose interface. As such its not really geared for large, complex off the shelf compose projects you might want to pull down for github, but rather simple single compose file projects. For a full fledged compose experience i would recommend something like Portainer.

There is nothing inherently wrong with USB3 flash drives that make them incompatible with unRAID. At one time (possibly still today) some motherboards had issues booting from USB3 drives but not from USB2 drives. I think those issues may have also included a tendency for the USB3 drive to drop offline periodically but dont quote me on that part. Additionally USB3 drives, particularly smaller form factor ones, tend to run much hotter than their USB2 counterparts, overtime that is probably not good for the flash memory. If those problems dont apply to your flash drive/mobo then a USB3 drive will likely work just fine.

The app store is not a built in component, it is community run and none of the apps are officially endorsed by unRAID. That said the important thing is that the unRAID host os not be exposed directly to the internet. Containerized apps are safer to expose (behind proper authentication) as they run isolated from the host os. The recommendation though has always been to use a VPN to access your home network and access all your services.

Can you see the files from the command line? If so the issue may be with permissions of the share and or the underlying data. If the issue is permissions unRAID has a tool for correcting the permissions of your data. If you already have Docker apps setup the new permissions tool can cause issues, but there is a plugin (Fix Common Problems I think) that has a docker safe new permissions tool.