Add NextExplorer as a selectable source for the Set Consume Folder action

[7thgenerationdesign]

Prerequisites

• I searched this repository's existing issues and this is not already requested.
• This is about the StartOS package — what it exposes, configures, or automates. A feature of the software itself belongs with the upstream project, not here.

What kind of change?

Add or change an action

Problem & use case

#9 shipped a great "Set Consume Folder" action: either a private folder (default, unchanged for existing installs) or a subfolder of FileBrowser Quantum's data volume, mounted read-write at /mnt/filebrowser, with PAPERLESS_CONSUMPTION_DIR pointed at the subfolder and the dependency declared only while that source is selected (the qbittorrent/metube pattern). That solved the core "put a user within reach of the consume folder" gap from #8 .

The remaining gap: the only file-server source is FileBrowser Quantum. Start9 is moving toward recommending NextExplorer as the primary file server, so the recommended file server can't currently back the consume folder. In my own setup my files now live in NextExplorer, and I'd rather not run FileBrowser Quantum solely to feed Paperless.

There's also a specific payoff: NextExplorer drives are surfaced inside Nextcloud as external storage, exactly the way FileBrowser Quantum's volume is. So a NextExplorer-backed consume folder gives Nextcloud users the same "drop-to-ingest for free" that #9's closing note describes for FileBrowser Quantum — satisfying my original #3 goal without Paperless taking a direct Nextcloud dependency.

Proposed solution

Extend the existing Set Consume Folder action to add NextExplorer as a third source option (private / FileBrowser Quantum / NextExplorer), reusing the exact pattern #9 established:

• read-write mount of the NextExplorer data volume at /mnt/nextexplorer,
• PAPERLESS_CONSUMPTION_DIR pointed at a chosen subfolder (default e.g. paperless), created by the image's own entrypoint,
• the nextexplorer dependency declared only while that source is selected,
• slotted into the now-argument-based bootstrap chain from feat: watch a FileBrowser Quantum folder as the consume folder #9 so it doesn't reintroduce the reactive-init re-run bug (the new watched value must not re-trigger bootstrapDatabase).

The one place this can't just copy FileBrowser Quantum is UID ownership, and it's the crux of the request. #9 avoided an idmap purely because Paperless runs as uid 1000 and FileBrowser Quantum serves its volume as uid 1000. Read-write is mandatory here — consumer.py unlinks the source file inside the same transaction.atomic() that stores the document, so a read-only mount rolls back every import and strands the written media. That means Paperless (uid 1000) must be able to both read and unlink files that NextExplorer writes into the shared folder. So:

• If NextExplorer also serves its data volume as uid 1000, this is a near-copy of feat: watch a FileBrowser Quantum folder as the consume folder #9 — no idmap.
• If NextExplorer uses a different uid, the action needs an idmapped mount (or equivalent) so uid 1000 can delete NextExplorer-created files. This is the main thing to determine and design around.

inotify is expected to work (it did across /mnt/filebrowser in #9, queuing within a second), so polling shouldn't be needed — but worth verifying it fires across the NextExplorer mount, with PAPERLESS_CONSUMER_POLLING as a documented fallback only if it doesn't.

Alternatives considered

• Keep it FileBrowser-Quantum-only. Works, but sidelines the now-recommended file server and means running a second file manager purely to feed Paperless.
• Direct Nextcloud read-write consume mount (my original Feature Request: Optionally share Paperless consume folder with Nextcloud for drop-to-ingest #3). Still valid, but heavier: a direct Nextcloud dependency plus its own UID/GID and sync-conflict handling for files that vanish post-consume. Routing through a NextExplorer drive that Nextcloud already surfaces gets the same drop-to-ingest outcome with less coupling — and reuses feat: watch a FileBrowser Quantum folder as the consume folder #9's proven mechanics.
• Manual upload via the Paperless web UI. No automatic/synced ingestion — the gap Wire the consume folder to a user-reachable source #8/feat: watch a FileBrowser Quantum folder as the consume folder #9 set out to close.

Anything else?

• Direct successor to feat: watch a FileBrowser Quantum folder as the consume folder #9 (Set Consume Folder) — same read-write mount, entrypoint-creates-subfolder, and dynamic-dependency (qbittorrent/metube) pattern; same argument-based bootstrap chain to avoid the reactive-init re-run bug feat: watch a FileBrowser Quantum folder as the consume folder #9 fixed.
• Related: Wire the consume folder to a user-reachable source #8 (wire consume to a user-reachable source) and Feature Request: Optionally share Paperless consume folder with Nextcloud for drop-to-ingest #3 (original drop-to-ingest); this extension largely satisfies Feature Request: Optionally share Paperless consume folder with Nextcloud for drop-to-ingest #3 via NextExplorer↔Nextcloud external storage.
• Key open question for the maintainer: what uid does NextExplorer serve its data volume as? That determines whether this is a straight copy of feat: watch a FileBrowser Quantum folder as the consume folder #9 or needs an idmapped mount.