[email protected]

Good catch, thanks for letting me know. Update is being pushed out now.

Most likely, I am in contact with the Dawarich developers regarding their Docker configuration.

I'll reach out, thanks!

I see the problem here, after digging through some issues on their GitHub. Lingarr gets the path to look for media from Radarr; the path to the media item inside Lingarr needs to be the same as the path to the item inside Radarr. This can vary from person to person, depending on how each person has their Radarr/Sonarr configured (and even from template to template; I know BinHex has different default paths from Hotio, for example). In your case, it seems you have "/media" used as the mapped root path for your media in Radarr. I'll update the template to make this requirement clear and remove the default so users have to consciously configure this moving forward. Thanks for letting me know.

Does it have to be specifically `/media` on the host, or just inside the container? Does this replace the `/app/media/movies` and `/app/media/shows` mappings? I don't see any updates to Lingarr's Docker Compose regarding this change: https://github.com/lingarr-translate/lingarr?tab=readme-ov-file#setting-up-lingarr

You can map the php.ini file inside the container to a file on the host machine through a mapped path. Looks like it might be at `/etc/php/8.3/apache2/pho.ini` inside the container: https://github.com/H2CK/webtrees/blob/webtrees-2.2/Dockerfile#L95

LimeTech is not involved in specific Docker container-related issues, so they are the wrong team to reach out to for that. The source code for WebTrees is maintained by H2CK on GitHub, though the Docker container for it is published on Docker Hub by "dtjs48jkt", who I assume is a different user simply publishing the image on H2CK's behalf. This sounds like an issue in the container itself in terms of PHP configuration and/or how the app interacts with the config. I would recommend reaching out to H2CK on the GitHub repository to report the issue. I am not personally a PHP dev, so unless there's something that needs to be changed on a Docker level, I am not going to be much help.

Fixed, updated template should be available soon, thanks for diagnosing this!

According to the project's documentation, configuring them as environmental variables should allow you to avoid that process: https://github.com/lingarr-translate/lingarr/blob/main/Settings.MD#settings Perhaps something to bring up with the Lingarr developer

Sorry, bug in the template from a bad copy-pasta, pushing out an update. If you'd like to fix it on your end in the meantime, delete the current "Internal Config File" entry and add a new one with the following details: Notably, the "Config Type" needs to be a "Variable", not a "Path".

I don't typically create icons for apps, I just use the icon that is provided by the app developer, if it exists. I understand it's annoying, trust me

Sigh, that's WAY too much customization via environmental variables that should be moved to just a single config file. Anyway, I've updated the template accordingly, thanks for letting me know!

1. The main application and the Sidekiq are very similar in terms of their environmental variables, and even use the same exact Docker image. The main difference between the two is the startup command (visible under "Post Arguments" in Advanced View), which trigger the container to either be a main server or a Sidekiq instance. The Docker Compose file for Dawarich has both containers configured, and in terms of Unraid, one template equates to one (and only one) Docker container. Hence, why both templates have to be installed as two separate "apps". 2-4. I understand that there have been some issues with the applications themselves in terms of the database setup process. As far as I can tell, this is not specific this Unraid template or running the Docker container on Unraid, and is an issue with the upstream application. I am keeping a close eye on various issue threads on the project's GitHub page for any updates, and am in communication with the developers about any changes needed for the template, including potentially transferring ownership of the Unraid template to the Dawarich team.

I'll get to it if I can. You can also submit a request to the SelfHosters repo, someone over there might pick it up in the meantime: https://github.com/selfhosters/unRAID-CA-templates

I can take a look if you send me details about the project

Might need to open an issue here: https://github.com/fisharebest/webtrees?tab=readme-ov-file

That sounds like an issue with the application itself, not the Docker template. I'd recommend reaching out to the webtrees developer.

Looking at some issues on their GitHub, it looks like they switched from 3000 to 8080 for the API. To clarify, you made the following edits: - Added Port 8080 mapping to Bar Assistant Backend to [B XXXX] (some unused host port) - Changed API_URL to http://IP_ADDRESS:[B XXXX]/bar on Bar Assistant Backend - Added API_URL variable (http://IP_ADDRESS:[B XXXX]/bar) to Salt-Rim - Added Port 8080 mapping to Salt-Rim to [F XXXX] (some unused host port) - Changed web UI port on Salt-Rim to map to 8080 If that is all correct, it seems like the backend is using port 8080 instead of 3000, and APP_URL on Salt-Rim should really be API_URL. And then the front-end Salt-Rim is using its own 8080 port as its web UI. If you can confirm, I'll update the templates accordingly.

daps-ui is in beta, can you direct your question to the daps-ui repo to involve the upstream dev? https://github.com/zarskie/daps-ui

Likely due to changing the UID and GID, please try the default values.

The upstream developer of the project is making some changes to their Docker image, I am in talks with them at the moment and will need to modify the Unraid template accordingly. Thanks for bringing this to my attention.

Thanks for bringing this to my attention. I've fixed the template accordingly.

Hmm, that's odd. There should only be one folder in `appdata/scratch_map`, a "database" folder that should already have read-write permissions out of the box. But thanks for the update.

This is best directed at the Threadfin GitHub page, as is is unrelated to the Unraid template.

Future travelers, conversation was resolved on GitHub: https://github.com/nwithan8/unraid_templates/issues/49