Ping Status is "ERROR" in Docker within Unprivileged LXC

[midwesternrodent]

Description

Homepage's status update for ping does not work with docker in an unprivileged LXC running Debian 12 on proxmox. The container is able to ping just fine when it is execed into, the actual status however is reported as "ERROR" on homepage. This is a duplicate of this discussion from about a year ago, but with some more information.

homepage version

v0.10.9 (p54daa, Jan 6, 2025)

Installation method

Other (please describe above)

Configuration

- Household:
    - Nextcloud:
        icon: /images/nextcloud.png
        href: https://nextcloud.mydomain.tld/
        description: Nextcloud is a complete replaceme
        siteMonitor: https://nextcloud.mydomain.tld
    - Printing:
        icon: /images/savapage.png
        href: https://print.mydomain.tld
        description: web printing service
        siteMonitor: https://print.mydomain.tld
    - Mealie:
        icon: /images/mealie.png
        href: https://mealie.mydomain.tld
        description: Mealie is a shared recipe book, m
        siteMonitor: https://mealie.mydomain.tld
    - Budgeting:
        icon: /images/actual.png
        href: https://budget.mydomain.tld
        description: Budgeting app that links to your 
        siteMonitor: https://budget.mydomain.tld
    - Vacuum:
        icon: /images/valetudo.svg
        href: https://vacuum.mydomain.tld
        ping: 10.0.10.2
    - Cameras:
        icon: /images/camera.png
        href: https://camera.mydomain.tld
        siteMonitor: https://camera.mydomain.tld

Container Logs

No response

Browser Logs

No response

Troubleshooting

Hey ya'll, this is a repeat of this discussion from about a year ago.

I recently migrated my docker containers to an LXC from a VM on proxmox for performance reasons. I understand this is not a recommended or supported setup, but I've gotten it working with all my containers just fine. The only problem I have amongst all of my containers, is that homepage is not able to ping anything. To be clear, I can exec into the docker container and can ping all of my services,, however the ping status on homepage just show's a red "ERROR" message like below for my robot vacuum. You'll notice items I'm using siteMonitor for are not affected by this and function just fine.

These are the results of a ping within the container while I was experiencing the issue. Not the most stable of connections for sure, but it is reaching the device.

PING vacuum.internal (10.0.10.2): 56 data bytes
64 bytes from 10.0.10.2: seq=0 ttl=62 time=85.486 ms
64 bytes from 10.0.10.2: seq=1 ttl=62 time=2.324 ms
64 bytes from 10.0.10.2: seq=2 ttl=62 time=29.938 ms
64 bytes from 10.0.10.2: seq=3 ttl=62 time=1703.800 ms
64 bytes from 10.0.10.2: seq=4 ttl=62 time=704.288 ms
64 bytes from 10.0.10.2: seq=5 ttl=62 time=2.643 ms
64 bytes from 10.0.10.2: seq=6 ttl=62 time=23.191 ms
64 bytes from 10.0.10.2: seq=7 ttl=62 time=11.328 ms
--- vacuum.internal ping statistics ---

8 packets transmitted, 8 packets received, 0% packet loss
round-trip min/avg/max = 2.324/320.374/1703.800 ms

When I curl the homepage API directly from an external computer, I get this error further confirming my permission suspicions. Curling the SiteMonitor API's returns the proper stauts for those objects.

myuser@mylaptop:~$ curl -L -k "https://homepage.mydomain.tld/api/ping?groupName=Household&serviceName=Vacuum"
{"inputHost":"10.0.10.2","host":"10.0.10.2","alive":false,"output":"PING 10.0.10.2 (10.0.10.2): 56 data bytes\nping: permission denied (are you root?)\n","time":"unknown","times":[],"min":"unknown","max":"unknown","avg":"unknown","stddev":"unknown","packetLoss":"unknown","numeric_host":"10.0.10.2)"}

I suspect this is a permission issue of some sort with the wrapper that homepage uses to access the "ping" command. Or possibly a sympton of the docker container's services running as root within the container. I know LXCs are limited on some network permissions with the host, for instance the IP address cannot be changed within the LXC. To confirm this, I spun up the container with privileged status, and sure enough the ping status is working now. However, a privileged LXC just for homepage seems to me a little much, so I'd like to narrow down the LXC or docker permissions needed for homepage so that ping can function without creating a security hole on my hypervisor.

Now I don't want to open an issue on this because quite frankly, Docker in an LXC is advanced and I don't expect project maintainers to spend their time on my edge case. However if we can find a simple fix, that'd be gravy. Really I'm trying to find if there's any way I can do an ID mapping in the LXC conf file to allow ping to work properly. Any assistance would be appreciated, I'll post here for an update if I find anything on my end.

[midwesternrodent]

Ah shoot, as soon as I post this I find the solution and thankfully it is stupid silly simple. Per node-ping's readme one of the FAQs is to install iputils. Sure enough, after running apk add iputils on the docker container's shell everything is working again. I will open an issue suggesting it be added to the docker container moving forward. (This is not a bug per Issue 2766 and Shamoon's confirmation below)

[midwesternrodent]

I'm going to reopen discussion here as I found issue 2766 was opened and determined to be not a bug. I'd respectfully ask that that issue is reopened. While it is certainly not a bug for docker in a VM, I don't think it would be detrimental to add to fix this weird edge case for other users who may be running this in an LXC. Also per node-pings issue log this is an issue with many other docker environments and the official fix from them is to install iputils. This project has now also seen at least three different people report the issue directly, sure that's not a high volume but how many users are going to take the time to open an issue? Please let me know your thoughts. I don't see any reason to avoid installing this in the container, but please feel free to educate me on the reasons.

[shamoon]

I don't see any reason to avoid installing this in the container,

Because this would change the origin of the ping from the host to the container, which is not how it’s worked for the year or two since it was implemented. And since as you said and the lack of other discussions about this would indicate, this is the edge case not the other way around I’m not that interested to change the current behavior

[midwesternrodent]

Fair enough. Would you welcome a PR for the docs? Maybe I could add a blurb to the troubleshooting section so future people don't re-open discussions here.

[shamoon]

Sadly, I often think that people dont seem to RTFM but that would be fine. Should be enough to add a brief admonition under the ping section

[midwesternrodent]

Ain't that the truth. Ok. I'll whip something up and submit it when I have time. Thanks!

EDIT: Apparently even for me, lol. Thanks for handling the PR, I'll do better for next time!

[github-actions[bot]]

This discussion has been automatically locked since there has not been any recent activity after it was closed. Please open a new discussion for related concerns. See our contributing guidelines for more details.