# 👥 Plusieurs comptes sur le NAS — sans WebDAV (Modèle C)

Objectif : faire cohabiter **plusieurs comptes** (toi, Alexia…) sur **ton propre NAS**,
chacun **isolé**, **sans** passer par WebDAV (limité : pas de miniatures, transcodage,
dédup, journal…). On garde **toutes les features de l'agent**.

## Principe : une instance d'agent par utilisateur

Le code de l'agent (`server.js`) est **partagé et inchangé**. Chaque utilisateur a sa
propre **instance systemd** avec :
- sa **racine NAS** (`NAS_ROOT=/mnt/nas-<instance>`) — `safeJoin` la cloisonne déjà :
  une instance **ne peut pas** voir les dossiers d'une autre ;
- son **partage NAS monté avec SON compte QNAP** → **isolation native QNAP** en plus du
  confinement applicatif (double barrière), et **droits d'écriture sur son espace** ;
- son **port**, son **token**.

Le **propriétaire** (Taaazzz) ne change pas : agent standard sur **:8080**,
`NAS_ROOT=/mnt/nas` (admin, voit tout). Les comptes ajoutés tournent sur d'autres ports.

```
                    ┌───────────────── Raspberry Pi ─────────────────┐
  app (toi)    ───▶ │ photosync-agent          :8080  NAS_ROOT=/mnt/nas        (admin) │
  app (Alexia) ───▶ │ photosync-agent@alexia   :8081  NAS_ROOT=/mnt/nas-alexia (son compte QNAP) │
                    └────────────────────────────────────────────────┘
```

> ⚠️ **SMB obligatoire sur le compte QNAP, même pour un utilisateur iOS.** PhotoSync
> ne fait JAMAIS parler le téléphone directement au NAS : le **téléphone parle à
> l'agent** (HTTP), et **l'agent parle au NAS en CIFS/SMB**. Donc le compte QNAP de la
> personne doit garder **Microsoft Networking (SMB) activé** — peu importe qu'elle soit
> sur Android ou iPhone. Activer « l'Apple (AFP) » à la place **ne suffit pas** et casse
> le montage (`mount error(13)`, cf. Dépannage).

## Pré-requis (une fois)

```bash
# Sur le Pi : installer le template d'instance + les outils
sudo cp pi-agent/photosync-agent@.service /etc/systemd/system/
sudo systemctl daemon-reload
sudo apt install -y qrencode          # pour afficher un QR scannable (optionnel)
```

## Ajouter un compte

```bash
# sudo ./add-photosync-user.sh <instance> <partage_qnap> <user_qnap> <port>
sudo ./pi-agent/tools/add-photosync-user.sh alexia PhotoAlexia_IOS2026 Alexia 8081
# → demande le mot de passe QNAP d'Alexia (masqué), monte SON partage avec SON compte,
#   crée l'instance, ouvre le port au LAN, et AFFICHE UN QR de connexion.
```

Le script affiche un **QR** encodant `{v:1, agent:{url, token}}` (url = `http://<IP
Tailscale>:<port>`, joignable partout via le tailnet). L'utilisateur **scanne ce QR**
depuis l'écran de connexion de l'app → configuré, isolé, prêt.

> Accès distant : pas besoin de `tailscale serve` par compte. Dans le tailnet, l'app
> joint directement `http://<IP Tailscale>:<port>` (la règle ufw `tailscale0` l'autorise).
> `serve` (HTTPS sur le hostname) reste réservé au compte propriétaire sur :8080.

## Retirer un compte

```bash
sudo ./pi-agent/tools/remove-photosync-user.sh alexia
# démonte, supprime l'instance/creds/env/règle ufw. Les DONNÉES NAS restent intactes.
```

## Garanties d'isolation (2 barrières)

1. **Applicative** : `safeJoin` interdit de sortir de `NAS_ROOT` (`..`, liens, fichiers
   cachés). L'instance d'Alexia ne voit littéralement que `/mnt/nas-alexia`.
2. **Native QNAP** : le partage est monté avec **le compte d'Alexia** → même si une faille
   contournait l'agent, le NAS lui-même refuse ce à quoi son compte n'a pas droit.

Le **token** de chaque compte vit dans `/etc/photosync-agent.<instance>.env` (**600
root**), jamais dans le bundle de l'app (cf. neutralisation des défauts côté app :
`mobile/.env.example`). Il se transmet par **QR**, pas en dur.

## Dépannage (incidents réels rencontrés)

- **`mount error(13): Permission denied`** + `dmesg` montre
  `STATUS_ACCESS_DENIED … Send error in SessSetup` : l'échec est à
  **l'authentification du compte** (pas sur le partage). **Cause rencontrée en réel
  (Alexia)** : le compte avait **SMB (Microsoft Networking) décoché** au profit de
  **l'Apple (AFP)** — l'agent monte TOUJOURS en CIFS/SMB, donc SMB doit rester actif
  (cf. ⚠️ ci-dessus). Autres causes possibles : mot de passe erroné (QNAP renvoie
  ACCESS_DENIED, pas LOGON_FAILURE), compte désactivé. → Sur le QNAP : **réactiver
  Microsoft Networking (SMB)** pour ce compte, vérifier qu'il est activé et a une
  permission R/W sur le partage ; au besoin réécrire `/etc/photosync-<instance>.cred`
  (masqué) et remonter.
- **`/shares` renvoie `[]` alors que le partage est bien monté** : la racine de
  montage `/mnt/nas-<instance>` était en **700 root** (créée sous `umask 077`) →
  l'agent (user `taaazzz`) ne peut pas la **traverser**. Corrigé dans
  `add-photosync-user.sh` (chmod 755). Pour une instance déjà créée :
  `sudo chmod 755 /mnt/nas-<instance>` puis `sudo systemctl restart photosync-agent@<instance>`.

---
Réfs : [PI-MIGRATION-BOOKWORM.md](../PI-MIGRATION-BOOKWORM.md),
mémoires `pi-hardening`, `photosync-token`, `chantier-ios-webdav`.