When an ownCloud-migrated group share (which has no per-user USERGROUP
subshare) is renamed for the first time, DefaultShareProvider::move()
inserted a new USERGROUP row without setting `accepted`. The column
defaulted to 0 (STATUS_PENDING), causing MountProvider to skip the
share on the next login — the shared file disappeared for the recipient.
Fix: set accepted = STATUS_ACCEPTED explicitly on the INSERT in
DefaultShareProvider::move() for the TYPE_GROUP branch.
Secondary fix: SharedMount::moveMount() silently returned true when
updateFileTarget() threw (e.g. group no longer exists on an OC-migrated
instance). Set $result = false in the catch block so View::rename()
propagates the failure instead of silently corrupting VFS state.
An opt-in occ command (sharing:fix-owncloud-group-shares) with --dry-run
support is included to repair existing broken instances. It targets only
TYPE_USERGROUP subshares with accepted=STATUS_PENDING and permissions!=0
(shares that were accepted but broken by the missing column default),
leaving explicitly declined shares (permissions=0) untouched.
AI-Assisted-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Signed-off-by: Anna Larch <anna@nextcloud.com>
