Skeleton files are copied into every account — offer mounting them as a share instead

[!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.

Every new account gets a physical copy of the skeleton (core/skeleton by default — 63 MB, 64 files, including Templates/, which also serves as the default templatedirectory). There is no deduplication: not in Nextcloud, and not in the object store underneath.

On our instance (Nextcloud 34.0.2.1, PostgreSQL, primary object storage on S3) this is what the storage actually holds:

95 % of our object storage is the Nextcloud manual, five times over. The single largest item is Nextcloud Manual.pdf at 29 MB, followed by Templates/ at 23 MB, Photos/ at 5.5 MB and Nextcloud intro.mp4 at 3.8 MB — about 63 MB per account.

This is more than a disk-space annoyance once primary object storage is in use, because the duplicate gets paid for several times over:

1. Network — each copy is uploaded to the object store when the account is created. On a self-hosted store behind a consumer uplink, that is a real and visible transfer.
2. Backup — each copy is fetched and stored again in every backup cycle.
3. Billing — with a hosted S3 provider, duplicated bytes are charged both as stored volume and as egress every time they are read or backed up.

At 200 accounts that is ~12.6 GB of byte-identical files. The cost scales linearly with the number of users while the information content stays constant.

Describe the solution you'd like

Nextcloud already has the right primitive for this — sharing. It just isn't used for its own skeleton.

Please consider an option (e.g. skeletonmode = copy | share, defaulting to copy for backwards compatibility) where, instead of being copied, the skeleton lives once in a designated account or group folder and is mounted as a read-only share into new accounts.

We tested that the existing share mechanism already answers the objections one would expect, on an unmodified Nextcloud 34:

• A user can opt out. Removing oneself from a group share returns 200, the folder disappears for that user only, and the other recipients keep their access. The share row is preserved with a per-user child row at permission 0 — so the opt-out is individual, non-destructive and reversible.
• Templates work from a share. Pointing a user's core/templateDirectory at a shared folder works: the templates API resolves it and lists its contents normally.

The resulting behaviour is arguably better than today's: users can still hide the demo content, and an admin can update the manual or the templates once for everybody, instead of shipping a copy that then ages independently in 200 home directories.

Describe alternatives you've considered

• Emptying skeletondirectory and sharing a folder manually. This is what we ended up doing, and it works — but it is undocumented as a pattern, has to be reinvented by every admin, and core/templateDirectory is a per-user setting with no global default that could point at a share, so it must be set for each account at onboarding time.
• Hard links instead of copies (#25562). Not applicable to object storage, nor to any setup where the data directory and the skeleton live on different filesystems.
• Simply shipping a smaller skeleton. Helpful, but it only changes the constant factor; the per-user duplication remains.

Additional context

Related but distinct existing issues:

• #35597 — configuring skeletondirectory from the web UI. About where the skeleton lives, not about copy-versus-mount.
• #5312 — skeleton written into a shared folder.
• #25562 — hard links instead of copies.

None of them proposes replacing the copy with a mount, which is the specific request here. The trade-off has also shifted since those were filed: object storage as primary storage is now common, and it removes both of the mitigations (filesystem deduplication, hard links) that made per-user copies cheap on a local disk.

Trace account creation's handling of core/skeleton and the per-user core/templateDirectory setting, then compare it with the existing share mechanism described in the issue. The work is done when a configurable copy-or-share mode preserves the current default, mounts the skeleton read-only for new accounts, and keeps template resolution and individual opt-out working.