`occ files:scan` crashes on stale federated shares after remote deletion

⚠️ 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

Bug description

occ files:scan <user> (and, more generally, any code path that walks a user's mounted
external/federated storages, e.g. background jobs) crashes with an unhandled fatal PHP
error when it encounters a federated share whose source share has been deleted on the
remote instance. Instead of skipping that single dead share, the crash aborts the entire
scan for that user — even if only one out of hundreds of shares is affected.

Steps to reproduce

1. On instance A, user alice shares a folder with user bob on instance B via
   federated sharing (share_type 6, or 9 for a group share). bob accepts it.
2. On instance A, the share is removed (e.g. alice unshares it, or her account is
   deleted) — the corresponding row in oc_share on instance A is gone, but the
   matching row in oc_share_external on instance B is not cleaned up (this can happen
   for several reasons and is arguably a separate issue, but is easy to reproduce by
   just deleting the oc_share row directly for testing).
3. On instance B, run occ files:scan bob (or occ files:scan bob -v).

Expected behavior

The scan should skip the dead external share (optionally logging a warning) and
continue scanning the rest of the user's files, finishing with the dead share simply
absent or marked unavailable.

Actual behavior

The scan aborts entirely with an unhandled fatal error. No further files are scanned
for that user in that run.

Root cause

In apps/files_sharing/lib/External/Manager.php, the Manager::$user property is
populated from $userSession->getUser() in the constructor. Under a CLI invocation
(occ), there is no active user session, so $user stays null.

When checkStorageAvailability() determines that a federated share is unreachable
(because the remote share no longer exists) and calls removeShare(), that method
eventually calls stripPath(), which dereferences $this->user->getUID() — on a
null object. This throws an unhandled Error, which is not caught anywhere in the
call chain, so it propagates all the way up and aborts the whole occ files:scan
process for that user instead of just failing to remove the one dead share.

Suggested fix

A few options, roughly in order of how surgical they are:

1. In Manager::stripPath() (or wherever $this->user->getUID() is called), guard
   against $this->user being null and fall back to resolving the UID some other way
   (e.g. from the share row itself, since the owning user is already known in that
   context) instead of dereferencing a null object.
2. Wrap the removeShare() call inside checkStorageAvailability() in a try/catch so a
   failure to remove one dead share logs an error and moves on, rather than bubbling up
   and aborting the whole scan.
3. More generally: CLI commands that walk external storages should ensure
   IUserSession::setUser() is set to the scanned user before touching code paths that
   assume an active session, so Manager::$user is never null in this context.

Happy to test a patch against our instances if one is proposed — we hit this
repeatedly across a small Nextcloud cluster (multiple nodes federating shares with
each other) and currently work around it by pre-emptively finding and removing dead
oc_share_external rows via direct DB queries before running occ files:scan.

Environment

• Nextcloud version: 33.0.4.1
• PHP version: 8.3.14
• Database: MySQL 8.0.29-21,
• Installation method: manual
• Affected apps: files_sharing (federated / external shares)

Steps to reproduce

1. On instance A, user alice shares a folder with user bob on instance B via
   federated sharing (share_type 6, or 9 for a group share). bob accepts it.
2. On instance A, the share is removed (e.g. alice unshares it, or her account is
   deleted) — the corresponding row in oc_share on instance A is gone, but the
   matching row in oc_share_external on instance B is not cleaned up (this can happen
   for several reasons and is arguably a separate issue, but is easy to reproduce by
   just deleting the oc_share row directly for testing).
3. On instance B, run occ files:scan bob (or occ files:scan bob -v).

Expected behavior

The scan should skip the dead external share (optionally logging a warning) and
continue scanning the rest of the user's files, finishing with the dead share simply
absent or marked unavailable.

Nextcloud Server version

33

Operating system

Debian/Ubuntu

PHP engine version

PHP 8.3

Web server

Nginx

Database engine version

MySQL

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?

• 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

Start in apps/files_sharing/lib/External/Manager.php and trace checkStorageAvailability() through removeShare() to stripPath(), focusing on the null Manager::$user during occ files:scan. Reproduce with a deleted remote share and a stale oc_share_external row, then verify the scan skips that share and continues processing the user's remaining files without an unhandled fatal error.