Nextcloud sync failing, "Connection Closed/Operation Canceled"

Support apps
,
1

I am fairly new to Yunohost, first server is about 3 months old. Yunohost is installed to a 512MB KVM VPS server with rainloop, borg and the main purpose, Nextcloud app. There’s no one using the mail, I just set it up for future use if they wanted it.

The other day, one of the users contacted me to say that syncing to her windows 10 desktop is no longer working. I added her account to my Nextcloud desktop client and began a sync and am able to reproduce her problem. In the desktop client, on specific files, I’m getting “Connection closed” and/or “Operation canceled” and then syncing stops (so I haven’t been able to sync everything else besides these). When I browse to the problem files in Chrome, the loading progress bar seems to load about 5% and then red banner comes up “Unexpected server response”. The “more information” says (edited by me):

PDF.js v1.9.426 (build: 2558a58d)
Message: Unexpected server response (0) while retrieving PDF “https://domain.ca/nextcloud/remote.php/webdav/edited_path/filename.pdf”.

The /var/log/nginx/domain-error.log outputs:

2019/02/25 04:05:23 [crit] 27965#27965: *1 open() “/var/lib/nginx/fastcgi/5/01/0000000015” failed (13: Permission denied) while reading upstream, client: 70.68.yy.xx, server: domain.ca, request: “GET /nextcloud/remote.php/webdav/edited_path/filename.pdf HTTP/2.0”, upstream: “fastcgi://unix:/var/run/php/php7.0-fpm-nextcloud.sock:”, host: “domain.ca”

It seems if I open a few other files in the browser (from the same directory, just other pdf files), then I can open the file that was giving the error in the browser. I just scrolled a few pages in the pdf, and it took more than a few seconds to load the page and had the spinning circle mouse icon while it was loading. Also, if I right click on it and “Save link as”, it seems to download the pdf ok.

The /var/log/php7.0-fpm.log contains warnings “WARNING: [pool nextcloud] child 17664 said into stderr: “ERROR: Unable to set php_value ‘always_populate_raw_post_data’””, but they do not happen at the same time as when trying to view or sync.

I’ve been testing with a pdf that is about 55MB from the current list of 5 files shown in the desktop client, but I noticed they are all 2.6MB or larger. When I look at all the files that load first try in the browser and have synced successfully already, they are all under 2.4MB. Could just be a coincidence or could be that smaller files just transferred faster on the initial sync. shrug

The files on the filesystem have the same permissions as the successfully syncing files. I don’t think this is really a permission issue and maybe an intermittent timeout issue. Something between nginx and php7-fpm? The keepalive_timeout is 65 in nginx.conf.

Any suggestions on where I should be focusing on next to troubleshoot this and get them back syncing?

Thanks in advance!

2

Are you using Nextcloud 13 or 15 ?
If 13, maybe v15 fix this ?

3

Sorry, was late at night when i posted and forgot to mention the problem happened while still running v13. When i saw v15 was released to stable the other day, I upgraded to v15 hoping to solve this or have some config checks point out the issue. No luck, no difference.

But i may have done an apt upgrade days prior and upgraded to latest yunohost and/or nginx. I’ll try and confirm from apt logs tonight.

Thanks

4

OK, this is pretty embarrassing now that it’s resolved. Googled the error some more and this time Google came through with first hit telling a guy to really double check his permissions. And I was just rechecking just to appease the steps, but sure enough:

root@domain:/var/lib/nginx/fastcgi# ls -la
total 48
drwx------ 12 www-data root 4096 Dec 18 09:58 .
drwxr-xr-x 7 root root 4096 Dec 15 22:47 …
drwx------ 102 www-data www-data 4096 Feb 25 09:14 0
drwx------ 102 www-data www-data 4096 Feb 20 08:51 1
drwx------ 3 root www-data 4096 Dec 17 12:23 2
drwx------ 4 root www-data 4096 Dec 17 13:50 3
drwx------ 4 root www-data 4096 Dec 17 13:50 4
drwx------ 3 root www-data 4096 Dec 17 12:23 5
drwx------ 102 www-data www-data 4096 Jan 11 16:11 6
drwx------ 102 www-data www-data 4096 Feb 4 09:24 7
drwx------ 3 root www-data 4096 Dec 17 14:15 8
drwx------ 101 www-data www-data 4096 Feb 20 08:48 9

Solution: chown -R www-data:www-data /var/lib/nginx/fastcgi

So I’m not sure how this problem went so long before getting noticed (coincidence and retries?), but it looks like permissions were broken on this server for months. I’m guessing this happened due to a stray pasted command in the wrong console without being noticed (happens too often with multiple monitors :frowning: )

Glad its finally resolved, though :slight_smile: Thanks and hope this saves someone else some unnecessary frustration.

2 Likes