10.3.1: "Server stopped accepting new streams before this stream was established"

When an ownCloud Desktop clients syncs with our ownCloud instance (recently updated to ownCloud 10.3.1), we often get the error

Server stopped accepting new streams before this stream was established

To me this sounds like a PHP-FPM configuration issue - but I am not sure what exactly could cause this problem.

On the server side, there are no entries for this error in the data/owncloud.log. On the client side, I tried to enable --logwindow - however, when logging is enabled, the syncing process of the ownCloud client (Windows) simply seems to hang up or time out when that error happens. The log file will contain the following:

11-26 12:21:35:984 [ warning sync.networkjob ]:	Network job timeout QUrl("https://owncloud.example.org/remote.php/dav/files/ownclouduser/some/folder")
11-26 12:21:35:984 [ warning sync.networkjob ]:	QNetworkReply::OperationCanceledError "Connection timed out" QVariant(Invalid)
11-26 12:21:35:984 [ info sync.networkjob.lscol ]:	LSCOL of QUrl("https://owncloud.example.org/remote.php/dav/files/ownclouduser/some/folder") FINISHED WITH STATUS "OperationCanceledError Connection timed out"
11-26 12:21:35:984 [ warning sync.discovery ]:	LSCOL job error "Operation canceled" 0 QNetworkReply::OperationCanceledError
11-26 12:21:35:984 [ warning sync.discovery ]:	Server error in directory "some/folder" 0
11-26 12:21:35:984 [ info sync.engine ]:	Sync run took  328229 ms
11-26 12:21:35:984 [ info gui.socketapi ]:	Sending SocketAPI message --> "STATUS:OK:…\\ownCloud" to QLocalSocket(0x796efb0)
11-26 12:21:35:984 [ debug sync.localdiscoverytracker ]	[ OCC::LocalDiscoveryTracker::slotSyncFinished ]:	sync failed, keeping last sync's local discovery path list
11-26 12:21:35:984 [ debug sync.networkjob ]	[ OCC::AbstractNetworkJob::slotFinished ]:	Network job OCC::LsColJob finished for "/some/folder"
11-26 12:21:35:984 [ info gui.folder ]:	Client version 2.6.0 (build 12644)  Qt 5.12.5  SSL  OpenSSL 1.1.1d  10 Sep 2019
11-26 12:21:35:984 [ warning gui.folder ]:	SyncEngine finished with ERROR
11-26 12:21:35:984 [ info gui.folder ]:	Folder sync result:  2
11-26 12:21:35:984 [ info gui.folder ]:	the last 1 syncs failed
11-26 12:21:35:984 [ info gui.socketapi ]:	Sending SocketAPI message --> "STATUS:OK:…\\ownCloud" to QLocalSocket(0x796efb0)
11-26 12:21:35:984 [ info gui.socketapi ]:	Sending SocketAPI message --> "UPDATE_VIEW:…\\ownCloud" to QLocalSocket(0x796f0e0)
11-26 12:21:35:984 [ info gui.socketapi ]:	Sending SocketAPI message --> "UPDATE_VIEW:…\\ownCloud" to QLocalSocket(0x796efb0)
11-26 12:21:35:984 [ info gui.application ]:	Sync state changed for folder  "https://owncloud.example.org/remote.php/dav/files/ownclouduser/" :  "Error"

Any help or tips would be appreciated.

Server configuration

Operating system:
Linux (Debian)

Web server:
Apache 2.4

PHP version:
7.3.12 (PHP-FPM served by Apache)

ownCloud version: (see ownCloud admin page)

Updated from an older ownCloud or fresh install:

The content of config/config.php:

List of activated apps:

Are you using encryption: no


I got that error too once, check all your timeouts (Apache, PHP, MySQL).
I’d have a good look in the MySQL logs, it’s probably the wait_timeout, max_allowed_packet combo which is your root cause.

EDIT: you seem to have a s***load of integrity errors, I’d suggest you check your files, you’d probably need to download a fresh copy of ownCloud.

1 Like

The integrity errors were due to Upgrade to 10.3.0: all files are listed as missing/invalid - this has since been rectified. // edit: I have updated the original post with the newest config dump

I’ll check the logs for timeouts.

Unfortunately there are no errors in the MySQL error.log coinciding with the errors reported by the ownCloud client. I checked the wait_timeout variable, which is at 28800 and the max_allowed_packet variable, which was at 16M. I increased the latter to 256M, restarted the MySQL server and tried again - but the error still happens unfortunately.

The only errors that seem to coincide are the following from Apache:

[Tue Nov 26 17:01:19.811110 2019] [proxy_fcgi:error] [pid 24501] (32)Broken pipe: [client] AH01075: Error dispatching request to : (passing brigade to output filters)

Unfortunately this doesn’t really say much, as there are no other error messages. If it was a PHP error, it would show up there. If it was a MySQL error, it would show up in the MySQL error log.

It looks like the error is at least unrelated to Apache or nginx, since the error also happens when using nginx (+ PHP-FPM). Which makes sense, since the error seems to happen somewhere inside the PHP-FPM proceess, rather than within the web server itself.

Looking at the source of the error message here it seems to have something to do with HTTP/2. To test, I disabled HTTP/2 on our server completely, then rebooted every service - and then also rebooted the ownCloud client. And now it does work indeed!

However, this would be only a work around for us, as we do not want to keep HTTP/2 disabled.


i just have found the following issue reported to the ownCloud team and i think this could be related:

I know, I opened the issue :wink:

1 Like


I am not an IT specialist so cannot really give detailed information on my curret set up and dig out the error in a log file. But I do experience the same error. I got the error while the software is still comparing files between my computer and my server. And no synchronisation activity occurs eventually, on any of my folders.

Does anybody manage to solve the issue or get some indication when we can expect the issue to be solved ?

Thanks for your help.

Get in touch with your server admin, perhaps link them to this thread as there is a workaround described earlier:

1 Like


it seems the next version 2.6.1 of the ownCloud client is disabling HTTP/2 again:

Sync: Temporary disable http2 support by default again (#7610)

1 Like


Any hint when 2.6.1 version will be released ?

The development is completely out in the open, so you can find the following release issue in github.

As you can see the first comment that the release was initially planned for the 20th December, but how it is often in software engineering, things take longer than expected. So I would think we’re still at least a couple of weeks away from a release.

1 Like