BoxBox v0.3.0: file and folder sharing for a self-hosted file manager
Description and use
BoxBox v0.3.0 introduces secure, token‑based file and folder sharing with access levels, expiration, revocation, and sandboxed previews, while maintaining consistency with dynamic mount configurations.
Problem
Providing secure, token‑based file and folder sharing for a self‑hosted file manager while preventing unauthorized access and ensuring consistency with dynamic mount configurations.
Outcome
BoxBox v0.3.0 enables secure, token‑based sharing of files and folders with fine‑grained access controls, expiration, revocation, and sandboxed previews, while maintaining consistency with dynamic mount configurations.
Workflow
- Generate a share token for a file or folder via the BoxBox UI or API.
- Receive a 43‑character URL‑safe token link.
- Share the link with recipients; the link includes a 32‑byte random token.
- Recipients access the link; BoxBox validates the token and resolves the path against the current mount config.
- If the token is valid and the path is within the share root, BoxBox serves the file or folder according to the access level (view, upload, upload+delete, full).
- For uploads, BoxBox writes to a temp file and uses renameat2(RENAME_NOREPLACE) to prevent overwriting existing files.
- If the link is revoked or expired, BoxBox returns a 404 for all failure cases.
- BoxBox ensures previews and ZIP downloads are sandboxed and do not expose internal paths or mount names.
- The share store is stored with 0700 permissions and the token file with 0600 permissions.
Evidence
Every file or folder gets a token link. Folder links come in four levels: View only, Upload only, Upload + delete, and Full access. Links can expire and can be revoked.
The token is the only credential. Each link is 32 random bytes from crypto/rand, encoded as 43 URL-safe characters.
Unknown, expired, and revoked tokens all return the same 404. Someone guessing tokens learns nothing about which links ever existed.
Upload-only means upload-only. Recipients with upload access must not overwrite existing files. Uploads land in a temp file and are published with renameat2(RENAME_NOREPLACE) on Linux, so the kernel refuses to replace an existing file atomically.
Recipient responses never include mount names or server paths. The share store is 0700, and the token-bearing shares.json is 0600.
- Record date: 2026-10-06T10:56:11.887Z