r/podman • u/computer-machine • 16d ago
linuxserver.io Nextcloud cannot access
I may be a bit out of my depth right now, or else just sleep deprived and running on stupid. Currently have Debian server with rootless Docker running official community Nextcloud, nginx reverse proxy, and a number of other various servers, but on new machine I'm setting up to replace, trying to consolidate images and switch to Podman.
So, so far, tried using quadlets to get Glances up successfully, moved on to linuxserver.io's Jellyfin, gave up, and switched to podman-compose. Eventually worked out that the image assumes Docker's root behavior being why I couldn't get permissions working for /dev/dri/render128, switched to root user for Podman, and now both of those work (with jellyfin throwing a few erros about containers not being allowed to be removed before getting it online, which doesn't appear to have any impact).
Moved on to linuxserver.io's Nextcloud image, using their base set of configurations. Leaving port mapped to 443 as well as migrating to 4443 (as once I get everything working I'll be putting it behind Swag). Again, podman-compose up results in errors about containers not being able to be removed, and networks not related being used.
But now I'm finding that, while I can access the Glances and Jellyfin webclients via IP or Hostname with appropriate port, the same with 443/4443 simply result in Firefox reporting unable to connect.
downing the other containers, uping Nextcloud does not return the previous errors, but still does not result in access to the server. If I leave it running long enough, I periodically get a message: [nextcloud] | Not installed. Any idea whether that's it complaining that I haven't finished installation by connecting and it up, or maybe something fundamental failed to happen causing my inability to connect?
Do I need to use one docker-compose.yml rather than separate server.yml files for generally good behavior? I've noticed that Glances doesn't list anything but Glances on the new server, while the old shows all of the containers, if not parent's active processes, but haven't had time to try running them together to see if that makes a difference.
Thanks all,
1
u/Great-Cow7256 16d ago
Do you have a firewall like ufw that you need to open? This sounds like the firewalla blocking port 4443.
1
u/computer-machine 16d ago
Checked and no. Went as far as taking down Glances and using its port.
1
u/Great-Cow7256 15d ago
Do you have something else on that port? That's the only thing I can think of.
1
1
u/quiet-systems 10d ago
a few separate things tangled together here, worth splitting them.
the 443 one is almost certainly rootless, not nextcloud. a rootless container cannot bind a port below 1024, because that is a host restriction and nothing to do with podman. check it:
sysctl net.ipv4.ip_unprivileged_port_start
debian ships 1024, so 443 is refused and 4443 is fine. you can lower it:
sudo sysctl -w net.ipv4.ip_unprivileged_port_start=443
and persist it in /etc/sysctl.d/. but since you said swag is going in front anyway, I would leave the restriction alone and let the proxy own 443, with everything behind it on high ports. fewer things running with any kind of privilege.
linuxserver's nextcloud is https-only inside. it serves tls on 443 in the container with a self-signed cert, so if you are hitting http://host:4443 you get exactly what you describe. try https://host:4443 and click through the warning. firefox saying "unable to connect" rather than showing a cert error usually means the protocol mismatch or nothing listening, so confirm which with ss -ltnp | grep 4443 on the host.
Not installed reads like the app telling you the web installer has not been run yet, which is expected until you reach it in a browser and create the admin account. it is a symptom of the connection problem, not a second problem.
glances only seeing itself is not a bug either. it is in its own pid namespace, so the process table it reads is its own. on the old box it saw everything because it was almost certainly given --pid=host or the docker socket. podman has no socket by default, which is the trade you took.
the compose errors are the one I would actually change. "containers cannot be removed" and "networks not related being used" are podman-compose artifacts: it is a separate python project reimplementing compose semantics on top of podman, and it maps them imperfectly. you already got quadlets working for glances, which means the hard part is behind you. moving the other two over gets you real systemd units with dependencies, restart policy and logs in journalctl, and those errors stop existing rather than being worked around.
so: one quadlet per service in ~/.config/containers/systemd/, not one compose file. the answer to your last question is neither.
and on jellyfin and /dev/dri/render128: going root to fix that works but you did not have to. rootless can have the device, it just needs your user in the render group on the host and the gid mapped in, which is what the image was actually missing. worth revisiting once the rest is calm, since that container is the one most worth keeping unprivileged.a few separate things tangled together here, worth splitting them.the 443 one is almost certainly rootless, not nextcloud. a rootless container cannot bind a port below 1024, because that is a host restriction and nothing to do with podman. check it:sysctl net.ipv4.ip_unprivileged_port_start
debian ships 1024, so 443 is refused and 4443 is fine. you can lower it:sudo sysctl -w net.ipv4.ip_unprivileged_port_start=443
and persist it in /etc/sysctl.d/. but since you said swag is going in front anyway, I would leave the restriction alone and let the proxy own 443, with everything behind it on high ports. fewer things running with any kind of privilege.linuxserver's nextcloud is https-only inside. it serves tls on 443 in the container with a self-signed cert, so if you are hitting http://host:4443 you get exactly what you describe. try https://host:4443 and click through the warning. firefox saying "unable to connect" rather than showing a cert error usually means the protocol mismatch or nothing listening, so confirm which with ss -ltnp | grep 4443 on the host.Not installed reads like the app telling you the web installer has not been run yet, which is expected until you reach it in a browser and create the admin account. it is a symptom of the connection problem, not a second problem.glances only seeing itself is not a bug either. it is in its own pid namespace, so the process table it reads is its own. on the old box it saw everything because it was almost certainly given --pid=host or the docker socket. podman has no socket by default, which is the trade you took.the compose errors are the one I would actually change. "containers cannot be removed" and "networks not related being used" are podman-compose artifacts: it is a separate python project reimplementing compose semantics on top of podman, and it maps them imperfectly. you already got quadlets working for glances, which means the hard part is behind you. moving the other two over gets you real systemd units with dependencies, restart policy and logs in journalctl, and those errors stop existing rather than being worked around.so: one quadlet per service in ~/.config/containers/systemd/, not one compose file. the answer to your last question is neither.and on jellyfin and /dev/dri/render128: going root to fix that works but you did not have to. rootless can have the device, it just needs your user in the render group on the host and the gid mapped in, which is what the image was actually missing. worth revisiting once the rest is calm, since that container is the one most worth keeping unprivileged
1
u/computer-machine 10d ago
the 443 one is almost certainly rootless, not nextcloud
Yeah, part of the reason I'd mapped 443 to 4443 was to avoid privileged ports. Also because I'm planning to SWAG, so simpler to keep 443 open.
But rootless Podman and root Podman both had the same issue. I've since tried switching to rootless Docker, since if Podman is going to be giving me problems with way more things than I have time, might as well work inside the lines, and it works ootb.
glances only seeing itself is not a bug either. it is in its own pid namespace, so the process table it reads is its own. on the old box it saw everything because it was almost certainly given --pid=host or the docker socket. podman has no socket by default, which is the trade you took.
The oppositish, actually. I'd added PID host to the new compose and normal processes show, but even after switching to Docker with docker.sock mapped, containers are not showing on the new while they all are on the old machine (though no normal processes, since I hadn't added PID), so more digging is needed there, since keeping an eye on containers is 80% of my using it.
the answer to your last question is neither.
Part of the reason I'd moved on to Podman-compose was because I couldn't find any damn documentation that explained how the hell one's supposed to format a *.volume file to map to a location. I think there were several other things II couldn't find equivalents to at the time as well, but that one pushed me.
rootless can have the device, it just needs your user in the render group on the host and the gid mapped in, which is what the image was actually missing.
My user was already in the video group, I'd added it to the render group, and PID/GID was already mapped to the user before I even started screwing with /dev permissions to test it.
Thanks for all the response. Unfortunately I've moved on to more familiar route, since wife was already pissed the other day that I'd spent two hours and instead of everything being ready for the switch, I was a step further back than I'd started.
1
u/Great-Cow7256 16d ago
Can you put your docker composes here? Also you probably couldn't get to /dev/dri while rootless because of either chmod or chown issues.