⚠️ This issue respects the following points: ⚠️
Bug description
occ share:list aborts with exit code 1 and produces no output at all as soon as a single orphaned share exists (a row still present in oc_share whose file id can no longer be resolved):
In Share.php line 169:
Node for share not found, fileid: 275263
One orphaned share makes the whole command unusable, e.g. for scheduled exports of all shares.
Orphaned shares are easy to accumulate in practice: they are left behind when a shared file is deleted directly on the storage (external storage / SMB) and also when a shared file is moved to the trash bin (shares are not removed on trashbin deletion, and DeleteOrphanedSharesJob only cleans them up once the file id is gone from the file cache completely).
Steps to reproduce
- Share a file (e.g. a public link share)
- Delete the file bypassing Nextcloud (e.g. directly on the storage / via SMB), then run
occ files:scan so the file cache entry is removed. The row in oc_share remains (orphaned share).
- Run
occ share:list
Expected behavior
The command lists the shares it can resolve; orphaned shares are skipped or marked instead of aborting the whole command.
Nextcloud Server version
32
Operating system
Debian/Ubuntu
PHP engine version
PHP 8.2
Web server
Apache (supported)
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
Probable cause: in apps/files_sharing/lib/Command/ListShares.php, execute() maps every share through $share->getNode()->getPath() without handling the NotFoundException thrown by Share::getNode() when the file id cannot be resolved. Still the case on current master. The command was introduced in Nextcloud 32 (#51399).
Bug description
occ share:listaborts with exit code 1 and produces no output at all as soon as a single orphaned share exists (a row still present in oc_share whose file id can no longer be resolved):One orphaned share makes the whole command unusable, e.g. for scheduled exports of all shares.
Orphaned shares are easy to accumulate in practice: they are left behind when a shared file is deleted directly on the storage (external storage / SMB) and also when a shared file is moved to the trash bin (shares are not removed on trashbin deletion, and DeleteOrphanedSharesJob only cleans them up once the file id is gone from the file cache completely).
Steps to reproduce
occ files:scanso the file cache entry is removed. The row in oc_share remains (orphaned share).occ share:listExpected behavior
The command lists the shares it can resolve; orphaned shares are skipped or marked instead of aborting the whole command.
Nextcloud Server version
32
Operating system
Debian/Ubuntu
PHP engine version
PHP 8.2
Web server
Apache (supported)
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
Probable cause: in apps/files_sharing/lib/Command/ListShares.php, execute() maps every share through
$share->getNode()->getPath()without handling the NotFoundException thrown by Share::getNode() when the file id cannot be resolved. Still the case on current master. The command was introduced in Nextcloud 32 (#51399).