QNAP Integration
Running Docker / QNAP Container Station. Homarr 1.6.0 running well, but I can't figure out how to integrate Homarr so it can 'see' the other containers. Does anyone know what the QNAP storage setup needs to be for this to work?
17 Replies
Thank you for submitting a support request.
Depending on the volume of requests, our team should get in contact with you shortly.
⚠️ Please include the following details in your post or we may reject your request without further comment: - Log (See https://homarr.dev/docs/community/faq#how-do-i-open-the-console--log) - Operating system (Unraid, TrueNAS, Ubuntu, ...) - Exact Homarr version (eg. 0.15.0, not latest) - Configuration (eg. docker-compose, screenshot or similar. Use ``your-text`` to format) - Other relevant information (eg. your devices, your browser, ...)
Frequently Asked Questions | Homarr documentation
Can I install Homarr on a Raspberry Pi?
Did you ever figure this out? It seems there's a problem with the "new" Homarr and QNAP Docker, because now (was late to upgrading) all my *arrs that are running on the same IP as Homarr cannot be reached, even though there's zero networking reason for this. Any IP that is not the Homarr IP is reachable and those integrations work (e.g. Pi-hole).
That is not a Homarr issue. It is a configuration problem. Do you our docker image directly?
I used the docker image and docker compose from the documentation. The thing is, all these integrations and connections worked with the old version of Homarr. I redeployed fresh and they all broke. There's no funny networking going on here, all services are bound to ports on the same host IP. Homarr sits at 192.168.40.190:7575 and Sonarr sits at 192.168.40.190:8989. Everything on my Homarr IP - which is every *arr - cannot connect. Anything on another IP does connect. There is just no reason for this. Prowlarr runs on the same IP and is used by the other arrs. Tdarr runs on the same IP and connects to Radarr and Sonarr for metadata. I'm not saying it is Homarr, but I don't see how it's not. 🙂
I did transfer my old config, but I tried building new apps and integrations fresh and that still does not work. That's actually worse since it seems you can't create an app if it cannot connect, which it cannot. So the only reason I have my apps on my board is from the restore.
It very well could be something weird with QNAP Docker but if it is I've never seen this before. Hence why I responded here in this thread first before opening a new issue. QNAP has come a long way too with their docker deployment and it's really nice now, so there's little reason for me to believe it's any different from native Linux docker. I can deploy Homarr on it's own IP if I had to.... but would prefer not to.
From inside the container I can ping the host IP so yeah... weird.
okay, I figured it out, and I do believe whatever is causing this is specific to Homarr.
Homarr has to be in the same docker network as the things it's connecting to. Which in my experience is weird because network connectivity to the host network just works. But for whatever reason Homarr - even though it's being configured with the host network target IPs - it's using the internal docker network to connect (I'm guessing but this is what my testing is revealing).
When using Docker Compose and specifying multiple containers in a single deployment, docker creates a new network for those components so that name services will work between them. Really common with databases and caching, you can use the internal docker name resolution of the container name and then you don't care what IP redis is running on AND you then don't have to open ports to the host IP just for internal app communication. This latter point is key, because you could do it this way. The internal docker network is irrelevant unless you're choosing to use it.
My Tdarr deployment is deployed in it's own docker network. But all my Arrs are deployed as standalone containers. Previously I deployed Homarr as an "Application" (QNAP thing) which uses docker-compose under the hood (I'm guessing/assuming) which makes deployment simple as I can just feed it the YAML. But in doing so it creates it's own network. Homarr seems to care about this.
Tdarr (as an example) on the other hand doesn't care about this, as it's service is mapped to the host the same way Homarr is. So for all intents and purposes it's running on the host IP and it reaches the internet from the host IP. It has no problem connecting to all my Arrs also running on the host IP, even though it's sitting in a separate docker network from the Arrs.
So, as of now with Homarr, since I need it to connect to Tdarr and my Arr suite, I have to deploy it to it's own IP (seemingly) so it can connect to everything. I haven't tested this but unless there's some magical fix coming soon for this issue this is the only path I see moving forward to make this work right.
which.... the default instructions say to use docker-compose... which means for everyone who installs using that process they're getting their own docker network. And literally 90% of people running Homarr has to be running it on the same host as their Arrs, which means they would be in separate networks and everyone would be having this issue. 🤔
There also doesn't seem to be documentation for UID and GUID environment variables so this container doesn't have to run as root? Each time I redploy the container it resets (I saw someone else with this issue) and while I see folders being written on my host path for configuration, it doesn't seem to pick it up when I redeploy. I for sure have to solve that and root before the rest of this even matters.
oh yeah, the documentation is even calling out the specific docker network... which.. tbh is a bit odd. No one is using internal docker networking to connect to their stuff except developers setting up multi-container apps.
so... TL;DR -> "Why can't Homarr connect to other containers through the host IP when Homarr itself is also using that host IP?"
Any input?
Thanks for the summary, Yes, the custom network may break it, as described in the docs.
This applies to any app, not only Homarr
I believe docker run doesn't create a network when creating containers
I have apps in separate docker networks that communicate through the host IP, I have never seen this issue with other docker apps
And old Homarr did not have this issue
Can you confirm that
curl or wget can connect?
Both from the homarr container and other containers?
If it can on non-Homarr but can't in the Homarr container, there might be an issue.
I run tons of containers myself but don't have any of these issues. Perhaps it's related to the setupif you're deploying your arrs and honarr in the same docker network you would not see this issue
I am not.
But sharing docker networks is not required for host networking
Hmm, well, I'll gather more info and provide, but I know there's nothing I can do differently. Even if I deploy homarr in the same docker network as my arrs, tdarr will always be in another docker network so that communication will not work
I understand. Please provide more info.
Capture with Wireshark if possible to see what's going on
Well, wireshark would need to be inside the homarr container for that to work
It will be tonight before I can get more details, but one thing I can say about this is obviously networking works to the same IP. Otherwise locahost and 127.0.0.1 would never work. But obviously systems connect "to themselves" all the time. But whatever is going on with Homarr it cannot. Docker is irrelevant. I'd be curious how the app would behave with no docker involved.