Context.
I’m packaging ecoDMS as an NS8 module. ecoDMS is a document archive system. It has several input options for PDFs, besindes others there is a scaninput folder — a watched drop directory where scanners/users deposit pdf documents, which ecoDMS then auto-imports and deletes. I want to expose it as a network share, ideally AD-authenticated. Inside the ecoDMS container this maps cleanly: if a volume is mounted at /srv/scaninput, ecoDMS symlinks its import folder to it (verified in the image’s check_env.sh). The question is purely how to serve that folder on the network.
Constraints:
- The Samba module (AD DC + file server) already binds :445 on the node IPs
- NS8 has no per-module “dedicated IP” primitive. The Samba module’s dedicated IP is an address the admin pre-configures on the NIC out-of-band; Samba merely bind()s it. There is no core action/UI to allocate one, and nothing that creates macvlan/ipvlan or a static-IP podman network for a module.
- Rootless modules are UID-isolated — each runs as its own Linux user with its own subuid range and 0700 home, so one rootless module can’t traverse into or delete files in another’s podman volume.
** Options**
-
WebDAV sidecar, routed through the existing Traefik HTTPS route (rootless, self-contained)
Add a small WebDAV container to ecoDMS’s own pod, sharing the same scaninput volume. Because it’s in the same pod / same module user, there is no UID-isolation problem at all — both containers see the volume natively. It rides the module’s existing Traefik
route (e.g. https://ecodms.example.org/scaninput/), so no extra port, no :445, no dedicated IP, stays rootless.
pro
– Fully portable, no privilege escalation, no coupling to the Samba module, ecoDMS keeps its own volume.
con
— WebDAV ≠ SMB: Windows can map it as a drive (WebClient service, HTTPS) but many MFP scanners speak SMB/FTP, not WebDAV. AD auth needs the WebDAV server configured to LDAP-bind against Samba (or Traefik forward-auth). -
Reuse the Samba server — rootfull bind-mount
Create a scaninput share on the Samba module; make ecoDMS rootfull and bind-mount the Samba share’s backing directory into the container. I verified a rootfull container can read and delete Samba-written files under enforcing SELinux, with Samba unaffected.
pro
– No credentials, instant ingestion, no second SMB server, real AD auth for the drop.
con
– ecoDMS becomes privileged (rootfull); only works when Samba is on the same node; reaches into the Samba module’s internal podman volume path (fragile if the instance is renamed/relocated). -
Reuse the Samba server — rootless smbclient poll sidecar
Keep ecoDMS rootless; a sidecar uses smbclient (userspace, no kernel mount, no privileges) to poll the Samba share every ~30 s,
copy new scans into ecoDMS’s local folder, and delete them from the share.
pro
– Rootless, no storage coupling, and works against a remote file server too.
con
– Needs a service-account credential to authenticate; ingestion is polled, not instant. -
Own SMB sidecar on an admin-provided dedicated IP
Run our own smbd in the ecoDMS pod and bind :445 on a second node IP the admin adds by hand (bind interfaces only), joining AD as a member for auth.
pro
– Self-contained, real SMB, decoupled from the Samba module.
con
– Requires a manual host-networking step (not portable — NS8 won’t manage/release the IP) and an AD member-join; heaviest option.
Considered and rejected: shared-disk volume + coordinated GID across two rootless modules (brittle cross-userns GID mapping); FTP/SFTP sidecar (port 21+passive range, or :22 clashes with host sshd); ecoDMS’s own web-client upload (licence-gated in the community image).
Question for the community
- Is there a supported NS8 pattern for cross-module file/share access that I’ve missed — e.g. a blessed way for module B to consume a share hosted by the Samba module, without going rootfull or reaching into its volume path?
- For a document-scanning drop folder, would you steer a module toward WebDAV-over-Traefik (A) for portability, or reusing Samba (B/C) for native SMB + AD? Any precedent modules doing either?