Context
The home server exposes a few drives over Samba for LAN access. There's already a FileBrowser instance running, but it's scoped to the whole filesystem rather than just the shared drives.
Idea
Worth evaluating a lighter-weight, scoped web UI for browsing the Samba-shared drives specifically, rather than the whole-system FileBrowser instance. Two candidate approaches:
Option A: Second FileBrowser instance, bind-mounted and scoped
- Pros: reuses existing tooling, direct filesystem access (fast), trivially scoped via volume mounts, simple docker-compose addition.
- Cons: bypasses Samba auth entirely (separate access path that could drift from SMB permissions), only works because it runs on the same host as the drives.
Option B: Filestash (or similar) using a native SMB/CIFS backend
- Pros: exercises the real Samba config/credentials end-to-end, portable to a different host since it's just an SMB client.
- Cons: heavier app, more config per share, SMB-over-loopback is wasted overhead when running on the same box as the shares.
Status
Not planned — just want this on record as a future option. No action needed right now.
Context
The home server exposes a few drives over Samba for LAN access. There's already a FileBrowser instance running, but it's scoped to the whole filesystem rather than just the shared drives.
Idea
Worth evaluating a lighter-weight, scoped web UI for browsing the Samba-shared drives specifically, rather than the whole-system FileBrowser instance. Two candidate approaches:
Option A: Second FileBrowser instance, bind-mounted and scoped
Option B: Filestash (or similar) using a native SMB/CIFS backend
Status
Not planned — just want this on record as a future option. No action needed right now.