Feature Request: Optionally share Paperless consume folder with Nextcloud for drop-to-ingest

[7thgenerationdesign]

Summary

As a follow-up to the read-only archive mount (see #2 ), it would be great to share Paperless's consume directory (/usr/src/paperless/consume) with Nextcloud, so that files dropped or synced into a Nextcloud folder are automatically ingested by Paperless.

This is intentionally separate from the read-only archive request because it requires read-write sharing (Nextcloud writes files in; Paperless consumes and deletes them), which is more involved and shouldn't block the simpler read-only feature.

Request

Provide an optional, configurable read-write share of Paperless's consume directory that Nextcloud can mount, enabled by users who have both packages installed.

Things to watch out for

• UID/GID compatibility (primary failure mode). Paperless typically chowns the consume folder to its own container UID/GID, which blocks external writes from Nextcloud. A shared UID/GID or a compatible permission scheme across the idmapped mount would be required.
• Consumer polling. Paperless's consumer often relies on inotify, which frequently does not fire reliably across bind/overlay/network-backed mounts. The shared-consume scenario will likely need PAPERLESS_CONSUMER_POLLING enabled (e.g. a 30–60s interval) so synced-in files are actually picked up.
• Delete-after-consume behavior. Paperless removes files from consume after processing; the Nextcloud-side folder behavior should account for files disappearing, to avoid sync conflicts or re-upload loops.

Alternatives considered

• Same as Issue 1 (manual export/re-upload; external WebDAV/sync container) — neither provides live, automatic ingestion.

[helix-a]

#9 covers this without a direct Nextcloud mount. Paperless can now watch a folder in FileBrowser Quantum (Set Consume Folder action), and nextcloud-startos already mounts FileBrowser Quantum's volume as Local external storage — which, unlike Nextcloud's primary storage, rescans on access, so files Paperless consumes and deletes disappear from Nextcloud too instead of lingering as stale entries. So with Paperless, FileBrowser Quantum and Nextcloud all installed:

1. In Nextcloud, enable FileBrowser Quantum as an external storage source (Nextcloud's own action).
2. In Paperless, run Set Consume Folder → FileBrowser Quantum → subfolder (default paperless).
3. Drop files into that folder from Nextcloud — web, desktop sync, or mobile — and Paperless imports them.

Each of the concerns in the request is handled on that path: the uid is shared (both Paperless and FileBrowser Quantum are uid 1000, and Nextcloud idmaps the volume to www-data), inotify works across the bind mount on the same kernel (verified: a file written from FileBrowser's container was queued within a second — no polling needed), and delete-after-consume is exactly what the external-storage rescan tolerates.

Mounting Nextcloud's own data directory read-write would need the Nextcloud username to locate data/<user>/files/…, and Nextcloud's primary storage does not check for out-of-band changes, so every consumed document would linger as a ghost entry until a manual files:scan. That's the sync-conflict scenario you flagged, and it's why the shared folder lives in FileBrowser Quantum instead.