-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Bug]: Links to other nextcloud instances (ocm_provider) which are not reachable (connection timeout) slow down webdav #42027
Comments
I experience the same behaviour, resulting in WebDAV-enabled clients timing out, etc. Figured out I've one federated share, which is currently down. For your situation that would be the Could you verify if this "remote nextcloud" instance is still accessible? Besides this cause, it would be nice if this error is reflected somewhere, or temporarily disable the remote/federated share after some attempts. Why is this causing a delay for a WebDAV call directly to a specific file, which is just locally in the root dir? `curl --user ':' 'https://nextcloud./remote.php/dav/files//' took around 11 seconds. |
I am also affected. The message "OCMProviderException" stays after deleting that specific OCM share from the admin sharing panel. Strange! |
Same problem. Also on users pages on url: I have a Caddy proxy (On Proxmox LXC) that refers to a Nginx+php-fpm (On Proxmox Debian VM) in same local network. All apps are slow (10s to 15s per actions). I have increase timeout on Nginx and php-fpm but same issue. Is anything to do ? |
Same problem here. Warnung no app in context StorageNotAvailableException Sabre\HTTP\ClientException: Failed to connect to xxxxxxxxx.dyndns.info port 4431 after 130047 ms: Connection timed out Currently running Nextcloud Hub 7 (28.0.2), but it has been like this since NC20. |
Fix with new rule LAN to LAN into top firewall. Nextcloud can look into itself |
"Fix with new rule LAN to LAN into top firewall. Nextcloud can look into itself" Whole error message: |
In my case, a physical firewall is present upstream of the host server (in addition to the host and VM firewalls). Is it any clearer? |
I have the same problem:
My questions here:
|
Related: #30552 |
Bug description
Opening a shared link (not related to the ocm-provider that's connection is broken) is very slow (took 10s to open a directory). After investigating i saw in the logs that there are timeouts on a ocm-provider in the (exactly) same time range. After removing this link the webdav's behavior was normal again.
In the UI there is no information that this ocm-provider is not working correctly. Only if you look at the detail pages. Maybe a hint on link level would be good.
Steps to reproduce
Expected behavior
Normal reactivity of webdav access on broken ocm-providers
Installation method
Community Docker image
Nextcloud Server version
27
Operating system
Debian/Ubuntu
PHP engine version
PHP 8.2
Web server
Nginx
Database engine version
MariaDB
Is this bug present after an update or on a fresh install?
None
Are you using the Nextcloud Server Encryption module?
None
What user-backends are you using?
Configuration report
List of activated Apps
Nextcloud Signing status
Nextcloud Logs
Additional info
No response
The text was updated successfully, but these errors were encountered: