Repository navigation
[BUG] Nextcloud notify_push fails if Nextcloud configured to serve http only #1150
Description
Is there an existing issue for this?
- I have searched the existing issues
Name of mod
nextcloud-notify-push
Name of base container
nextcloud
Current Behavior
If I configure the Nextcloud nginx config (default.conf) to serve only port 80, notify_push fails to load properly. I get the following in the logs:
nextcloud | **** Making sure the Nextcloud Client Push plugin is installed and enabled ****
nextcloud | notify_push already installed
nextcloud | notify_push already enabled
nextcloud | **** Starting notify-push ****
nextcloud | [2026-05-16 16:55:40.348782 +10:00] ERROR [notify_push] src/main.rs:84: Self test failed: Error while communicating with nextcloud instance: error sending request for url (https://localhost/index.php/apps/notify_push/test/version)
nextcloud | Connection to localhost (127.0.0.1) 7867 port [tcp/*] succeeded!
nextcloud | **** Setting notify_push server URL to https://cloud.mydomain.net/push ****
nextcloud | ✓ redis is configured
nextcloud | ✓ push server is receiving redis messages
nextcloud | ✓ push server can load mount info from database
nextcloud | [2026-05-16 16:41:18.771454 +10:00] WARN [notify_push] /build/source/src/lib.rs:289: Error while trying to get cookie from Nextcloud error sending request for url (https://localhost/index.php/apps/notify_push/test/cookie)
nextcloud | 🗴 push server can't connect to the Nextcloud server
nextcloud | error sending request for url (https://localhost/index.php/apps/notify_push/test/cookie)
nextcloud | **** Retrying notify_push setup ****
etc
I have traced the issue to /etc/s6-overlay/s6-rc.d/svc-mod-nextcloud-notify-push/run. In the first few lines:
#!/usr/bin/with-contenv bash
export NEXTCLOUD_URL="https://localhost"If I change https to http in the third line:
export NEXTCLOUD_URL="http://localhost"Then everything loads properly:
nextcloud | **** Making sure the Nextcloud Client Push plugin is installed and enabled ****
nextcloud | notify_push already installed
nextcloud | notify_push already enabled
nextcloud | **** Starting notify-push ****
nextcloud | Connection to localhost (127.0.0.1) 7867 port [tcp/*] succeeded!
nextcloud | **** Setting notify_push server URL to https://cloud.mydomain.net/push ****
nextcloud | ✓ redis is configured
nextcloud | ✓ push server is receiving redis messages
nextcloud | ✓ push server can load mount info from database
nextcloud | ✓ push server can connect to the Nextcloud server
nextcloud | ✓ push server is a trusted proxy
nextcloud | ✓ push server is running the same version as the app
nextcloud | configuration saved
nextcloud | [ls.io-init] done.
This is a functional workaround, but will fail when I next update the image.
Expected Behavior
It should be possible to run the nextcloud container as HTTP only without causing these issues. If I've understood properly, the issue only impacts when the notify_push mod first starts and performs its self test. I assume it works properly after then (or maybe I'm wrong and it stays broken).
So why am I doing this?
I use SWAG as my reverse proxy. I would prefer - as for most other containers - that TLS is applied only in SWAG. It's not great practice to double TLS, so it would be better that the Nextcloud container serves only HTTP. I have a specific reason to do this: my corporate laptop has Netskope forced upon it; Netskope does all kinds of terrible things in the name of security, including messing up anything that involves double TLS.
Steps To Reproduce
- Deploy Nextcloud using
docker composeand apply the nextcloud-notify-push mod - Use SWAG to reverse proxy Nextcloud using only internal docker networking
- Deactivate 443 in the Nextcloud
default.conf - Start Nextcloud, observe the errors noted above
(I appreciate that this is a bit non-specific, but hopefully my comments above are sufficiently clear - let me know if you need more)
Environment
- OS: Debian Bullseye
- How docker service was installed: per docker instructionsCPU architecture
x86-64
Docker creation
services:
nextcloud:
image: linuxserver/nextcloud:33.0.3
container_name: nextcloud
environment:
- PUID=912
- PGID=912
- DOCKER_MODS=linuxserver/mods:nextcloud-notify-push
volumes:
- /mypath/config:/config
- /mypath/data:/data
depends_on:
- redis
restart: unless-stopped
networks:
- swag_proxy-net
- redis-net
redis:
image: redis:8.6.3
volumes:
- /mypath/redis:/data
restart: unless-stopped
container_name: redis
networks:
- redis-net
networks:
swag_proxy-net:
external: true
redis-net:
driver: bridgeContainer logs
As above
Activity
aptalca commentedon May 16, 2026
NEXTCLOUD_URLneeds to be the public url of your nextcloud instance for it to work properlyneponn commentedon May 17, 2026
Thanks for the quick reply @aptalca. That was one of the first things I tried. It didn't help. To be clear, I added the following to my
docker_compose.yml:I've also confirmed that the
NEXTCLOUD_URLenv is passed into the container.But the start-up log contains the same error:
The
/etc/s6-overlay/s6-rc.d/svc-mod-nextcloud-notify-push/runscript seems to be ignoring the env variable.aptalca commentedon May 17, 2026
You're confusing me.
Don't set the env var nextcloud url, it's only used internally.
The nextcloud url setting in NC settings has to be the public url.
You can do whatever you want for your reverse proxy connection but don't remove the listen for 443 in NC's nginx conf. There is absolutely no reason to do so as it's only listening inside the container.
neponn commentedon May 18, 2026
I have to confess to being a little confused myself. You suggested I should ensure
NEXTCLOUD_URLis the public URL of my Nextcloud instance. I thought setting the environment variable was the best way to do it. If not, how should I go about it?I take your point that Nextcloud listening to 443 is not an inherently bad thing, but it does seem a bit odd that a self test of the push server would test a path that is not actually used. Testing
https://localhostwhen all traffic is served via port 80 to SWAG doesn't seem like a robust test.aptalca commentedon May 18, 2026
Follow the readme. Do nothing more, nothing less. Don't modify the default behavior of the app like removing nginx listen on port 443.
Https has been the default method recommended for our Nextcloud image since its inception. For the majority of its life, it was the only supported method. SWAG's default connection is also https:
https://github.com/linuxserver/reverse-proxy-confs/blob/master/nextcloud.subdomain.conf.sample#L33
It's not just a test. It's how the push service communicates with Nextcloud
LinuxServer-CI commentedon Jun 18, 2026
This issue has been automatically marked as stale because it has not had recent activity. This might be due to missing feedback from OP. It will be closed if no further activity occurs. Thank you for your contributions.
LinuxServer-CI commentedon Sep 17, 2026
This issue is locked due to inactivity