Repository navigation
[Bug]: Unreachable federated share remote blocks the user's whole filesystem: Files never loads (OCM discovery timeout on every request) #65766
Description
⚠️ This issue respects the following points: ⚠️
- This is not a troubleshooting question, general support matter, or webserver/proxy problem, but likely a bug (if unsure, ask the Community Help Forum).
- This issue is not already reported on Github OR solved at the Community Help Forum (I've searched!).
- I'm using a maintained major version of Nextcloud Server and tested against the latest patch level. (Supported major versions and current patch levels).
- I agree to follow Nextcloud's Code of Conduct.
- I've tried my best to provide clear reproduction steps that someone unfamiliar with this bug could use to reproduce it.
Bug description
A user with an accepted federated share from a remote server that does not respond (connections time out instead of being refused) cannot use the web Files app at all. The page shows a loading spinner indefinitely.
During every filesystem setup for that user, files_sharing\External\Storage::__construct() calls OCMDiscoveryService::discover() synchronously. Each call blocks until the 10-second cURL connect timeout. A failed discovery is not cached, and the share is not marked unavailable, so every request for the user waits again.
Users without the federated share work normally on the same instance, with the same external storages.
Example: the remote server was offline for an extended period (taken down by its operator). occ user:info <user> took 20.6 s for the affected user (two 10 s timeouts) and under 1 s for other users.
Steps to reproduce
- User A on server 1 accepts a federated share from server 2.
- Make server 2 unreachable so that TCP connections time out, not refused (for example, drop packets to it).
- Log in to the web interface of server 1 as user A and open Files.
- Run
occ user:info Aand time it.
Expected behavior
An unreachable federated remote should affect only that share, not the user's whole filesystem.
Nextcloud Server version
35
Operating system
Debian/Ubuntu
PHP engine version
PHP 8.5
Web server
Apache (supported)
Database engine version
MariaDB
Is this bug present after an update or on a fresh install?
Updated from a MINOR version (ex. 32.0.1 to 32.0.2)
Are you using the Nextcloud Server Encryption module?
None
What user-backends are you using?
- Default user-backend (database)
- LDAP/ Active Directory
- SSO - SAML
- Other
Configuration report
List of activated Apps
Nextcloud Signing status
Nextcloud Logs
Additional info
No response
Activity
vasyugan commentedon Oct 22, 2026
Wow, just wasted several hours on this...
Seeing the same on Nextcloud 34.0.5.1 (AIO, Apache reverse proxy). A federated share
from a remote server that is currently unreachable makes every authenticated request
of the affected user slow, not only Files (WebDAV PROPFIND, calendar REPORT,
notify_push/uid, recommendations API).
Log findings (warn level, 7 minutes, 40 requests):
exactly 20 s later, "error while discovering ocm provider" (cURL error 28 after
10001 ms for https:///ocm-provider). The cached failure does not seem
to prevent a new attempt.
(base.php:987) -> Filesystem::initMountPoints -> UserMountCache::registerMounts ->
MountPoint::getStorage -> External\Storage::__construct (files_sharing
External/Storage.php:75) -> OCMDiscoveryService::discover().
External\Storage::test() (Storage.php:191) and files_lock
LockService::getRemoteLockFromDav, both via OC\Files\Storage\DAV::propfind
("Failed to connect to :443 after 133761 ms"). Longest request: 155 s.
Expected: an unreachable remote should not block mount setup for the whole user.
Ideas: negative-cache the remote for some minutes, don't contact the remote in the
Storage constructor / mount registration, and use a short connect timeout.
Workaround: delete the row from oc_share_external.
9R commentedon Oct 22, 2026
Not a permanent solution, but at least a workaround for the current situation, while many nextcloud servers might be down because of PHP: It is possible to find the external shares in the database and disabling the unreachable servers temorarily.
example for postgresq:
listing shares:
SELECT id, remote, name, accepted, mountpoint, "user" FROM oc_share_external;deactivating unreachable shares:
UPDATE oc_share_external SET accepted = 0 WHERE id = <id>;I strongly recommend creating a db-backup before running above commands.
Declined shares can be accepted later in the web-ui with files -> pending shares
Having the option to remove unreachable, accepted shares via webconfig would be useful.
vasyugan commentedon Oct 22, 2026
Thanks. But indeed, this shouldn't be necessary, the Nextcloud server should be able to handle such situations gracefully. If the impact of federated shares is that the functioning of one's own server depends on the availability of someone else's, outside one's control, then this becomes risky and impractical. Wasn't the Internet itself designed to survive wars and other situations where many individual nodes become unavailable? If it is so trivial to bring down someone's server, this even seems like a potential attack vector for malicious actors.
hochwasser commentedon Oct 23, 2026
This bug is also present in the 34.0.3 and the 34.0.5 release with a postgresql database and redis as cache.