Files

T

Claude a8446f8371 Q19 resolved: storage convention is plain host bind-mount, not SMB volume

The Karakeep compose user shared confirms every container in LXC 104
uses host bind-mounts of /mnt/pve/unas/services/<svc>/<vol> directly.
No driver_opts, no CIFS, no per-volume credentials. The earlier
SMB-as-docker-volume proposal in this repo was over-fitting to the
Nextcloud-specific NFS issue and is withdrawn.

The Nextcloud failure was Nextcloud-specific: its setup tooling chowns
the data dir to www-data, which fails against root_squash exports.
Normal containers don't trigger that path, so plain bind-mounts work
fine.

Changes:

- docs/09 §Step 3: compose block dropped from ~30 lines (volume,
  driver_opts, CIFS device, credentials env) to a one-line bind-mount
  + env_file. Added a pre-deploy `mkdir -p` for the UNAS service +
  backup paths. Explanatory note retained for future agents.
- docs/12 #27 marked withdrawn pointing to #31. #31 rewritten with the
  bind-mount pattern (was SMB-default). #36 (UNAS audit) now looks for
  `- /var/lib/docker/...` or anonymous volumes as the non-compliant
  signal.
- CLAUDE.md storage block: bind-mount is the standard, SMB is
  documented escape-hatch only.
- docs/11: Q19 moved into Resolved with the new framing. Q12 + Q20
  grouped under a new "## Backups" section header (the now-empty
  "Verification needed" section removed).
- docs/13 Task 1 struck through with done-marker pointing to docs/09.

Net: Phase-3.1 deployment YAML is now actually deployable as written.

2026-05-05 05:01:48 +00:00

4.2 KiB

Raw Blame History

13 — Information Wishlist

What additional system inventory would sharpen future decisions, packaged as the smallest set of paste-and-run tasks that still answers everything material. Each task is independent — run any subset, in any order.

Each task header tells you exactly where to run it (which shell or which UI). Output goes into a Memos draft, a comment in this conversation, or docs/inventory/<NN>-<slug>.txt — whichever is easiest.

Task 1 — Stack inventory + reference compose ✅ DONE

User pasted the Karakeep compose. Q19 resolved → host bind-mount of /mnt/pve/unas/services/<svc>/<vol> is the convention. Nexa stack updated in docs/09 §Step 3. The docker ps -a half (running-container inventory) is still useful when we get to housekeeping #36 (UNAS-integration audit) — but that's not blocking now.

Task 2 — Storage map (Proxmox + docker)

📍 Where: Two shells — first the Proxmox host (Datacenter → nuc → Shell, or ssh root@192.168.1.20), then back into the LXC 104 console.

Tells us which Proxmox storage backs what, and which docker volumes are local vs. SMB.

# (a) on the Proxmox host (192.168.1.20):
cat /etc/pve/storage.cfg
cat /etc/pve/lxc/104.conf

# (b) on LXC 104 (192.168.1.40):
docker volume ls
ls -l /dev/dri/      # confirms whether iGPU passthrough actually works

Unblocks: optimization #30 (iGPU), #36 (UNAS audit), B6/B7/C17.

Task 3 — Postgres / DB workload inventory

📍 Where: LXC 104 console (same shell as Task 1).

Direct input to housekeeping #35 (consolidate postgres instances).

for c in $(docker ps --format '{{.Names}}' | grep -iE 'postgres|mariadb|mysql|_db$'); do
  echo "=== $c ==="
  docker exec "$c" sh -c 'psql -U postgres -l 2>/dev/null || mysql -e "show databases" 2>/dev/null'
done

Unblocks: #35 (consolidate vs. migrate-to-SQLite decision).

Task 4 — LiteLLM model list for the Nexa key

📍 Where: Either the LiteLLM admin UI (one screenshot) or any shell with $SAIA_API_KEY exported.

Screenshot path: open https://ai.nuclide.systems (Lobehub) → Settings → Model List, filtered to the Nexa virtual key. Screenshot the model rows.

CLI path: any shell on your PC or the LXC, with SAIA_API_KEY set:

curl -sH "Authorization: Bearer $SAIA_API_KEY" \
  https://ai.nuclide.systems/v1/models | jq '.data[].id'

Unblocks: Q18 follow-up — which embedding model SAIA proxies and at what dim, so we can decide if any flow can short-circuit TEI.

Task 5 — S3 archive credentials

📍 Where: s3.nuclide.systems admin UI in your browser (it's already proxied via Zoraxy — same login as the rest of the homelab).

Walk to: Buckets → either pick an existing Nexa-suitable bucket or create one called nexa → note the bucket name. Then Access Keys → create a key named nexa-snapshots with read/write on that bucket → drop the access-key + secret into Vaultwarden under "Nexa S3", and reply here with just the bucket name (the secret stays in Vaultwarden).

Unblocks: Q12, housekeeping #37 (S3 archive tier), Phase-3.3.

Task 6 — Reverse-proxy + DNS authority (only if needed)

📍 Where: two browser UIs.

Zoraxy (http://192.168.1.4:8000) → HTTP Proxy → either click "Export" if available, or take a full screenshot of the table.
AdGuard (http://192.168.1.20 LXC 102 web UI) → Filters → DNS Rewrites → screenshot.

Skip unless we hit a routing surprise during Phase 1.

When something else is needed

The smaller items (n8n credentials list, Memos webhook config, smartctl, sample of _sortMe/, what cron is failing) only matter when we touch that specific area. The agent will ask for them at the moment they're needed, with the same "📍 Where" framing.

Self-serve once Phase 6 ships

Once Phase 6 — Nexa as homelab steward lands, Nexa runs Tasks 1–3 itself on a schedule and folds the results into a daily drift report. This wishlist becomes a Nexa-managed surface (#nexa:wishlist-status) rather than something the user has to remember.

4.2 KiB Raw Blame History Unescape Escape