[files_external] Changing an External Storage mount backend or path silently destroys all metadata (previews, Albums, Recognize, Maps, shares)

[!TIP]

Help move this idea forward

• Use the 👍 reaction to show support for this feature.
• Avoid commenting unless you have relevant information to add; unnecessary comments create noise for subscribers.
• Subscribe to receive notifications about status changes and new comments.

Is your feature request related to a problem? Please describe.

When a user needs to change the backend or path of an existing External Storage mount (e.g. migrating from SMB/CIFS to a local bind mount, or moving an SMB share to a different server), Nextcloud currently provides no supported migration path. Any change — whether through the Admin UI or occ — silently creates a new storage_id in oc_storages, leaving all previously indexed files in oc_filecache orphaned under the old storage_id.

The consequence is a total, silent loss of all derived metadata tied to the original fileids:

• Generated previews / thumbnails
• Recognize face & object recognition data
• Photos app Albums
• Maps GPS photo positions
• Favorites and tags
• Shared links (internal and external)

This is especially painful for small organizations and associations that have invested significant time building photo libraries with years of curated Albums, trained face recognition, and geolocated memories — only to lose everything when performing a routine infrastructure change (e.g. replacing a network share with a faster local mount) on files that are physically untouched.

Related prior discussions confirming this is a recurring, systemic issue:

• https://github.com/nextcloud/server/issues/57524 — same problem when changing SMB server path or IP; manual SQL workaround confirmed to work but entirely undocumented officially
• https://github.com/nextcloud/server/issues/43861 — same problem when changing datadirectory; persistent side effects even after full rescan
• https://help.nextcloud.com/t/change-external-storage/241381 — community user with the same question, no automated solution available

Describe the solution you'd like

Two complementary improvements:

1. In the Admin UI — when editing an existing External Storage mount, allow modifying the backend type or path in-place, preserving the existing storage_id and all associated metadata, rather than silently creating a new storage entry. This could be gated behind a clear warning ("This will remap the existing mount. Ensure the files are identical before proceeding.").

2. An occ command — a dedicated command to migrate an existing mount to a new backend or path while keeping all fileids intact, so previews, Albums, Recognize data, Maps, favorites, and shares are fully preserved. No implementation is prescribed here — the Nextcloud team is better placed to design the right API. A dry-run option would be strongly appreciated.

Describe alternatives you've considered

• Editing the mount in the current UI: Always creates a new storage_id, destroying all metadata. Not viable.
• Manual SQL on oc_storages and oc_filecache: Works in practice, but is dangerous, completely undocumented, inaccessible to non-technical admins, and unsupported. Not a real alternative for most users.
• Full rescan after migration: Restores file visibility but destroys all metadata. Unacceptable for photo-heavy or long-lived installations.

Additional context

Concrete scenario: a small non-profit organization running Nextcloud on a Synology NAS (Docker) with a large shared photo library mounted via SMB External Storage. After years of use, the library has curated Albums, trained Recognize models, GPS-tagged photos on Maps, and thousands of generated previews. The organization wants to replace the SMB mount with a local bind mount of the same physical drive — files are byte-for-byte identical, only the transport layer changes. Under the current behavior, this routine infrastructure improvement would silently destroy years of organized metadata with no recovery path short of dangerous, undocumented SQL manipulation.

The underlying data model already supports this operation — fileids are stable identifiers and metadata is keyed on them. The missing piece is a safe, supported interface to remap a mount without discarding that relationship.

Start by tracing the existing External Storage Admin UI and occ handling, then inspect how oc_storages and oc_filecache represent the mount and file IDs. Define a safe migration path that preserves the existing storage_id and file IDs, with clear warnings and a dry-run option if feasible; done means changing the backend or path no longer orphanes the associated metadata.