Hello,
I have Nextcloud 21 running with php-7.4, httpd(8) and relayd(8). On my laptop, a script regularly runs nextcloudcmd to synchonize the files with the nextcloud instance. And quite often, nextcloudcmd returns such error: 03-31 23:28:56:089 [ info nextcloud.sync.networkjob.lscol ]: LSCOL of QUrl("https://nextcloud.tumfatig.net/remote.php/dav/files/user85419/Uploads") FINISHED WITH STATUS "UnknownNetworkError Network access is disabled." Both run OpenBSD 6.8/amd64. It seems that it only happens when I access nextcloud via relayd. If I access nextcloud straight via httpd, the error never pops up. Running relayd in debug mode, I saw the following difference: * when traffic works ok relay https_lan, session 2 (1 active), 0, 192.168.1.76 -> :8083, done, [Host: nextcloud.tumfatig.net] [User-Agent: Mozilla/5.0 (OpenBSD) mirall/3.0.1git (Nextcloud)] [nextcloud.tumfatig.net/ocs/v1.php/cloud/capabilities: format=json] GET -> 127.0.0.1:8083; [Host: nextcloud.tumfatig.net] [User-Agent: Mozilla/5.0 (OpenBSD) mirall/3.0.1git (Nextcloud)] [nextcloud.tumfatig.net/remote.php/dav/files/user85419/Uploads] PROPFIND; * when the error occurs relay https_lan, session 1 (1 active), 0, 192.168.1.76 -> 127.0.0.1:8083, done, [Host: nextcloud.tumfatig.net] [User-Agent: Mozilla/5.0 (OpenBSD) mirall/3.0.1git (Nextcloud)] [nextcloud.tumfatig.net/ocs/v1.php/cloud/capabilit ies: format=json] GET -> 127.0.0.1:8083; As you may notice, we can see "192.168.1.76 -> :8083" when it's working and "192.168.1.76 -> 127.0.0.1:8083" when it fails. But I can't see the reason for it in my relayd configuration. I've attached it to this mail. Any thoughts on what I'm doing wrong? Thank you, Jo |
On 21/03/31 23:50, Joel Carnat wrote:
> Hello, > > I have Nextcloud 21 running with php-7.4, httpd(8) and relayd(8). > On my laptop, a script regularly runs nextcloudcmd to synchonize the files > with the nextcloud instance. And quite often, nextcloudcmd returns such error: > 03-31 23:28:56:089 [ info nextcloud.sync.networkjob.lscol ]: LSCOL of > QUrl("https://nextcloud.tumfatig.net/remote.php/dav/files/user85419/Uploads") FINISHED > WITH STATUS "UnknownNetworkError Network access is disabled." I did some reading on the issue.[1][2][3] It appears to affect some users on other platforms if the 'Use system proxy' setting on the desktop client is enabled (though some reported that the presence/absence of the option didn't seem to affect anything). As an experiment, you could temporarily disable keep-alive in relayd.conf(5). It probably won't fix anything (in which case you can revert it), but it's worth trying imo. https://marc.info/?l=openbsd-misc&m=150287292709311&w=2 [1]: https://github.com/nextcloud/desktop/issues/482 [2]: https://github.com/nextcloud/desktop/issues/865 [3]: https://github.com/nextcloud/desktop/issues/2628 -- https://amissing.link |
On Thu, Apr 01, 2021 at 01:47:11PM -0600, Ashlen wrote:
> On 21/03/31 23:50, Joel Carnat wrote: > > Hello, > > > > I have Nextcloud 21 running with php-7.4, httpd(8) and relayd(8). > > On my laptop, a script regularly runs nextcloudcmd to synchonize the files > > with the nextcloud instance. And quite often, nextcloudcmd returns such error: > > 03-31 23:28:56:089 [ info nextcloud.sync.networkjob.lscol ]: LSCOL of > > QUrl("https://nextcloud.tumfatig.net/remote.php/dav/files/user85419/Uploads") FINISHED > > WITH STATUS "UnknownNetworkError Network access is disabled." > > I did some reading on the issue.[1][2][3] It appears to affect some > users on other platforms if the 'Use system proxy' setting on the desktop > client is enabled (though some reported that the presence/absence of the > option didn't seem to affect anything). > Thanks. I found those links and tried to set parameters on the nextcloudcmd. But I couldn't find how to say "don't try to use a proxy". So I'm not sure if it tries to do something with that setting or not. I also tried passing the credential via .netrc or via parameters. But that didn't change anything. > As an experiment, you could temporarily disable keep-alive in relayd.conf(5). > It probably won't fix anything (in which case you can revert it), but it's worth trying imo. I have tried it and it doesn't change the erroneous behaviour. I also tried to set a tcp protocol forward rule (based on SSH example from manpage) but the failures also happen. Finally I trie using a hostname in the table definition (rather than using 127.0.0.1) but that was no luck. I wrote a script that would run the GET and PROPFIND commands found in the logs, using curl. And those never fail. So this would look like nextcloudcmd has something buggy. But using nextcloudcmd to connect directly to httpd (via ssh tunnel) also make the failure disappear. The only work-around I can see now is to modify my crontab to ensure consecutive syncs don't happen too frequently... Regards, Jo |
Free forum by Nabble | Edit this page |