首次启动时自动生成的 .secrets 包含多套密钥：JWT_SECRET（登录会话）、LICENSE_ENC_KEY（用于加密 / 解密你本地保存的 API Key、密码、密钥）、HMAC_SECRET（授权心跳验签）。它们只存在于你的服务器，BestNav 官方无法获取，也不会上传。
妥善保管 .secrets 与 data 目录备份。迁移或重装时务必先恢复 .secrets，否则已加密的凭据将无法使用。
View Logs per Platform
All BestNav editions run the same Go binary; startup and runtime logs go to stdout, collected differently per platform: the Docker engine for container editions, systemd-journald for fnOS, and a bestnav.log file in the data directory for the Synology SPK (redirected by its start script). How to view per platform:
Docker / Synology Container Manager / QNAP / ZSpace (container): docker logs bestnav, or docker logs -f bestnav to follow; errors only with docker logs bestnav 2>&1 | grep "\[ERROR\]"
Synology SPK (native install, NOT a container): logs live in /var/packages/bestnav/target/data/bestnav.log, view as root: sudo tail -n 100 /var/packages/bestnav/target/data/bestnav.log; follow with sudo tail -f on the same path
fnOS: managed by systemd under the service name bestnav (the retired name was bestnav-direct); logs live in the journal, NOT a file. View with journalctl -u bestnav -n 100 --no-pager; follow with journalctl -f -u bestnav
Debugging Pro license / plugin issues (e.g. a stuck “Pro features are loading” banner): grep "\[Pro\]" in the respective log — it prints the exact failure reason
Note: the data/logs/ folder under the app data dir is only an empty dir pre-created by the start scripts — BestNav never writes program logs there; on fnOS startup logs appear only in journalctl. If systemd says the unit is not found, check the name with: ls /etc/systemd/system/ | grep bestnav (you can safely delete a leftover bestnav-direct.service).
Back Up Your Data
A full backup is just a tar of the data. Docker keeps data in the named volume bestnav_data (pack it with the command below); native installs (fnOS / Synology) use the data dir chosen at install time (usually on the app data disk). The backup contains bookmarks & config, users & license, license.json, auth.json, uploaded files, auto-backups, and most importantly .secrets (the encryption key file).
Bash# Docker example: tar the named volume bestnav_data
docker run --rm -v bestnav_data:/data -v $PWD:/backup alpine \
tar -czf /backup/bestnav-data-$(date +%F).tar.gz -C /data .
# fnOS / Synology native example (use your actual path)
tar -czf bestnav-data-$(date +%F).tar.gz -C /path/to/appdata data
If .secrets is lost, locally encrypted API Keys / passwords / keys become permanently undecryptable — back it up too
Also export config JSON from Settings → Data as a supplement
Schedule scripted backups (keep last 7 days) and copy one copy offsite or to cloud
To migrate: stop the old service → tar data → transfer to the new device → extract to the same-name data dir → start. After restore, .secrets and data are identical.
Recover / Reset Admin Password
If you forget the admin (founder) password, reset it from the command line — no reinstall, no data loss, and no restart needed (the service re-reads auth.json on every login, so the reset takes effect immediately). The subcommand is always reset-password (no leading dashes); type the new password twice when prompted (hidden input, min 6 chars). The "Forgot password" link on the login page also prints the matching command for your install method. Per platform:
Bash# Docker / Synology Container Manager / QNAP / ZSpace (official image)
docker exec -it bestnav /app/bestnav reset-password
# Use the actual name from docker ps; for the generic compose (alpine variant) the binary is /tmp/bestnav
# Synology SPK (native install, not a container; run as root, arch auto-selected)
sudo -i
cd /var/packages/bestnav/target
DATA_DIR=/var/packages/bestnav/var/data ./server/bestnav-linux-$(uname -m | grep -qE "aarch64|arm64" && echo arm64 || echo amd64) reset-password
# On very old SPK builds where data still lives in target/data, use DATA_DIR=./data instead
# fnOS (app-center edition, no systemd unit since 2026-09-24; paths auto-read from the running process)
sudo -i
PID=$(pgrep -f "server/bestnav" | head -1)
BIN=$(readlink /proc/$PID/exe)
DD=$(tr "\0" "\n" </proc/$PID/environ | grep "^DATA_DIR=" | cut -d= -f2-)
echo "BIN=$BIN DATA_DIR=$DD" # both values must be non-empty
DATA_DIR="$DD" "$BIN" reset-password
# fnOS legacy (still systemd-managed: /etc/systemd/system/bestnav.service exists)
sudo -i
BIN=$(grep ^ExecStart= /etc/systemd/system/bestnav.service | cut -d= -f2)
"$BIN" reset-password
The subcommand must be exactly reset-password — -reset-password / --reset-password is not recognized and the program just starts normally
New fnOS installs (since 2026-09-24) have no systemd unit — the old grep bestnav.service / systemctl stop bestnav commands no longer apply; DATA_DIR must be set explicitly (the command above reads it from the running process env; usually /vol*/@appdata/bestnav/data)
On fnOS / Synology SPK the binary is NOT in /usr/local/bin (legacy commands are deprecated) — use the real paths above
The new password is typed interactively (hidden, twice, min 6 chars); piping it in (echo xxx |) will NOT work — use an interactive SSH terminal
Since v1.0.3 running the reset as root automatically hands auth.json back to the service user; on older versions chown it manually — the owner shown by ls -l is authoritative (sc-bestnav on DSM 7)
Reset affects only the login password; bookmarks, stored API Keys and the .secrets encryption key are untouched
If the Synology binary name is unclear, check the arch suffix: ls /var/packages/bestnav/target/server/
Member passwords are reset by the admin in Settings → Users, no CLI needed
About the Encryption Key
The auto-generated .secrets holds several keys: JWT_SECRET (login sessions), LICENSE_ENC_KEY (encrypts/decrypts your locally stored API Keys, passwords, keys), and HMAC_SECRET (license heartbeat signing). They exist only on your server — BestNav cannot access or upload them.
Keep .secrets and the data backup safe. On migration or reinstall, always restore .secrets first, or encrypted credentials will be unusable.