primeval_god

Indeed, the compose file you attached uses volumes to store data instead of bind mounts (host directories). You will want to remove the 'volumes' section at the bottom and then replace each volume name in the rest of the file with a host path. This volumes: - mosquitto-conf:/mosquitto/config - mosquitto-data:/mosquitto/data becomes something like volumes: - /mnt/user/appdata/mosquitto/config:/mosquitto/config - /mnt/cache/appdata/mosquitto/data:/mosquitto/data

See here https://docs.docker.com/storage/bind-mounts/#use-a-bind-mount-with-compose volumes: - type: bind source: /mnt/user/appdata/myapp target: /folder/in/container

If the containers are on the same custom bridge network (not the default bridge) then you should be able to use the container name as the database host. Custom bridge networks have an internal DNS mapping for each container so containers can reference each other by name.

Many containers available in User Applications (and many found in the wild) have environmental variables like PUID and PGID that allow you to specify the user and group that the app in the container runs under. Match those to nobody:users on the unRAID host. It will not survive reboot. You would have to use a user script or go file mod to make that change on every boot. unRAID is not really designed with security at the forefront. Its inclusion of docker is more aimed at providing simple to install apps rather than hosting internet facing services. If security of your hosted apps is your primary concern i would recommend running a VM with a more general os and run your secure docker services on that.

You should not install things directly on the unRAID host, and this is one of the reasons why. Use a docker container instead https://hub.docker.com/r/linuxserver/ffmpeg. Your script can launch the ffmpeg container just as easily as it could launch a native app.

Try docker compose instead of docker-compose

The point is that unRAID doesnt use file permissions the way general purpose linux does. The users you create in unRAID only exist from the perspective of share level network security. Under the hood linux users and groups are not really used to control file access. Applications that run directly on unRAID run as root, applications in containers are expected to have their container permissions mapped to nobody:users on the unraid host and only be given bind mounts to the specific directories need as a means of controlling what they can access.

Another possible piece of the puzzle i am running netdata/netdata:v1.28.0

Also in case you werent aware when two containers are connected to the same custom bridge they have a DNS mapping for each other matching their container name.

Interesting I have both as well as SYS_PTRACE, though i am not 100% sure if extra parameters is where i had them as i switched netdata to compose a while ago. Also not sure if it makes a difference but i dont have my netdata container connected to the Host network. Its on a custom bridge with a port mapping for 19999.

Try adding the following to the extra parameters field of your netdata container. --pid=host --cap-add SYS_SYS_ADMIN

Try Netdata

If you are using a reverse proxy container and both it and the container you are proxying are connected to a custom bridge docker network for internal communication then there is no need to make map the application containers ports to the accessible ports on the unraid host. Without the port mapping the only way to access the application is through your secured reverse proxy.

This is not currently possible with this plugin.

The plugin is called compose manager. Just search for compose in the plugins category of community apps.

The first thing you will need is a reverse proxy app to route all of your applications through a single authenticated address. I personally use traefik with organizr as an authentication app. That said these are probably more complete alternative solutions .

Docker is the recommended way to install/use applications in unRAID. Its another one of the particulars of the unRAID system. Docker application containers (especially those available in community applications) allow applications to be somewhat isolated from the system so they can only access intended data and are isolated from compatibility issues with unRAIDs stripped down OS. Plugins on the other hand are more for things that require direct integration with the OS or webui.

Here is a plugin I maintain, i wont promise that it is the best designed plugin ever but i think the build scripts might be worth looking at https://github.com/dcflachs/compose_plugin. It was originally forked from Squids user.scripts plugin so at least the bones of it were created by someone competent in unRAID plugin development.

Technically yes though doing so may be challenging. The plugin system/architecture is poorly documented at best. Adding new pages/tabs of the webui is reasonably simple, modifying or extending existing ones is quite a bit more complex and more hacky. For prior art on displaying drive related info the source for the unassigned drives plugin or the zfs plugin might be a good place to start. As for why this was brought up, The unRAID OS is not really designed with the usage of traditional RAID arrays or other storage architectures beyond the core unRAID array (looking at you ZFS) in mind. The ability to use btrfs raid pools is a rather new addition and still designed in service of a main unRAID array. When questions pop up about other RAID levels and hardware RAID it tends to be from newer uses who dont really understand what unRAID is and how its is meant to be used.

It has been suggested earlier in this thread that counterfeit devices may end up intermingled with legitimate devices due to how Amazon controls products in their warehouses. See comment below.

At this time compose manager only manages stacks created from its interface. When you add a stack in the webui it creates a folder on the flash drive and populates it with a new compose.yml. You could try copying the contents of your obico-server folder into the folder created by a compose manager stack.

Are you aware of this plugin?

When you say they stick do you mean a docker inspect shows that the labels are not updated or that the webui doesnt pick up the changes and modify its links? What version of unRAID are you running? The translating of labels to webui links is a feature of the unRAID os rather than this plugin specifically, if thats the issue we may have to raise this to limetech. There should be no reason to reload the page, it should auto refresh when the editor closes. Also you shouldnt have to do compose down and then compose up again. Running compose up on an already running stack should recreate its containers if anything has changed in its config file.

This will not change if you switch to this plugin. Containers managed via this plugin can be updated via a button in the gui however their update status does not integrate with unRAID's native dockerman ui and so the "update ready" label will continue to be present.

Issues with booting from usb3 ports has been a somewhat common issue in the past. It was never clear to me if it was due to linux support for booting from usb3 controllers or if it was issues with some of the earlier usb3 controller hardware. It has been less of an issue recently but still crops up from time to time. Not sure if the qnap platform has issues with this. The recommendation for unraid is typically a usb3 drive in a usb2 port when possible for the best compatibility. There is a global help button, not sure if you have found it, that reveals help text throughout the webui. Much of the built in functionality has fairly robust help text in my opinion. While mirroring is supported in cache pools it is not really intended to be the primary method of redundancy. Unraid is built around the unraid array (which in my opinion is its star feature). The unraid array is parity protected with single or dual redundancy options while still allowing each data disk to be read independently.