RC2 of 23.0.3 and RC2 of 22.2.6 are ready for testing!

Maintenance releases 22.2.6 and 23.0.3 are coming next week and RC2 for both is now available on our download server.

As always, help with testing is very much welcome!

We updated our servers, did our tests, and the release candidates seem pretty decent. Still, give it a whirl and report back here so we’re even more sure that it’s good to go!





Thank you!

1 Like

Why are the bug-fix point releases of 23.0.x not on the GitHub releases page? The latest v23 release there is still v23.0.0 is flagged

Those are just stable releases. The release clients (RC) and betas are not included there.

Unsure on exactly what is going on though since the last 22 release listed is from November.

Yes, I understand that those are stable releases. And there is no just about it. Those are the latest bugfixes to the current release and they absolutely should be showing on the GitHub releases pages and 23.0.2 release should be showing as Latest, not 23.0.0 which is 2 bugfix releases behind current.

They seem to be tagged:

1 Like


I would like to test the 22.2 issue on my server but a v.21 release is running on it and I wouldn’t interfere with it. So, is it possible to have an other beginning of data base than “oc_" ; I would like to have “cob_" for exemple.
Tell me.

Thanks for you help.



Hanssonit Ubuntu VM is throwing Apache2 syntax errors, server down after updates…

Sure. You can have as many nc instances on a server as you like. Either you use a common datase with separate prefixes (as you said) or you use different databases. Also the data directories and the vhost settings of the web server must be separate. At best you create separate subdomains.

To test new releases before I upgrade the main instance, I have a subdomain testcloud.my-domain.de with an own database, data directory and an entry in /var/www/testcloud.

desktop clients not receiving notifications through notify_push if the server uses a self signed certificate (NC 23.0.3 final version and desktop client 3.4.4)

notify_push successfully started on the server but the Nextcloud desktop clients did not receive any notifications via notify_push. I was observing this in the context of Nextclouds “High Efficiency Backend for Documents”.

The reason for this behaviour of the desktop client was (as observed in the debug logs of the Nextcloud desktop client), that it did not successfully establish a ws connection with notify_push on the server, because the desktop client did not accept a self signed certificate used by the server for the ssl connection. But the same certificate was accepted by the Nextcloud desktop client for the standard way of polling the server and syncing the client with the server.

The obvious solution was to use a valid Let’s Encrypt ssl certificate on the Nextcloud server. To implement that on a nextcloud intranet instance was non-trivial as it requires a FQDN as a server URL.

As indicated by “sudo -u www-data /var/www/nextcloud/occ notify_push:metrics”, with a valid ssl certificate used by the server, now the active connection count is incremented by one if a Nextcloud desktop client is startet and decremented if it is closed. File syncronisation with the desktop client starts immediately upon changes on the Nextcloud server as expected.

Here are some details of the setup:

Nextcloud Server:
Nextcloud version (eg,
Operating system and version (eg, Ubuntu 20.04): Debian GNU/Linux 11 (bullseye)
Apache or nginx version (eg, Apache 2.4.25): nginx/1.18.0
PHP version (eg, 7.4): v7.4.28

Nextcloud Desktop Client
Version 3.4.4 (macOS)

(Note: after the installation of the client push app (0.3.0) on the Nextcloud server the corresponding notify_push binary was missing the executable bit; ‘chmod +x notify_push’ solved it)

It would be very helpful if the desktop client and/or notify_push could be modified so that notify_push is also working with self signed certificates out of the box. Would you please consider that ?