This is a Docker volume issue, not a code bug. The backend container
only sees paths explicitly mounted in docker-compose.yml. A new mount
on the Linux host (e.g. NAS share, USB drive) is invisible to the
container until added as a volume — restarting the container alone
doesn't help, and restarting just the host doesn't either.
Backend: New GET /api/filebrowser/diagnose endpoint reads
/proc/self/mountinfo and returns the actual bind/nfs/cifs mounts the
container sees, plus a check of common candidate roots (/audiofiles,
/mnt, /media, /srv, /home, /app/data) showing whether they exist and
have content.
Frontend: Info icon in FileBrowser header toggles a diagnose panel
showing mounts and root candidates. Quick-access buttons now built
dynamically from candidate roots that actually exist. On 'path not
found' error: helpful inline explanation including the exact .env
variable and docker-compose command needed to add a new mount.
docker-compose.yml: New EXTRA_AUDIO_PATH env variable. Mounts a
second host path 1:1 (same path inside container, like
AUDIOFILES_PATH does). Defaults to ./data → /extra_audio_unused
when unset, which is a no-op.
.env.example: Documents EXTRA_AUDIO_PATH usage with example.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Previously AUDIOFILES_PATH=/media was mounted as /audiofiles in the
container, so the file browser showed /audiofiles instead of /media.
Now the host path is preserved inside the container, so /media stays
/media. The default (./audiofiles) still maps to /audiofiles.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
