docs(nfs): prawa do udziału opisane zgodnie z tym, co jest naprawdę

Runbook kazał robić `chown apps:apps` na użytkownika, którego na tym NAS-ie nie
ma, i nie tłumaczył, DLACZEGO zapis się nie udaje. A przyczyna jest myląca:
kontener działa jako root, NFS domyślnie stosuje root_squash, więc root z klienta
ląduje jako `nobody` — czyli w kategorii „inni", dla której świeży dataset
(drwxrwx--- root root) nie daje żadnych praw. `ls` w podzie pokazuje przy tym
„root root", co sugeruje, że wszystko jest w porządku.

Teraz są dwa jawne warianty: prostszy (mapall_user: root, katalog bez zmian —
squash wyłączony dla TEGO JEDNEGO udziału, w którym leży jeden plik) i czystszy
(dedykowany użytkownik + chown). Dopisane, czego nie robić: chmod 777 zadziała,
ale uczyni katalog zapisywalnym dla każdego lokalnego użytkownika NAS-a, a leżą
tam hashe haseł.

Dołożona sekcja rozstrzygająca „jeśli mimo wszystko Permission denied": trzy
komendy pokazujące jednocześnie stronę kontenera, stronę eksportu i stronę
katalogu, plus opis zestawu, który działa.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

astrololo/README-stan-prezentacji.md

@@ -44,22 +44,44 @@ Jeśli `Tank1` nie jest pulą ZFS albo wolisz zwykły katalog:
 sudo mkdir -p /mnt/Tank1/astrololo-state
 ```
 
-### Właściciel i prawa
+### Właściciel i prawa — TU JEST NAJCZĘSTSZY BŁĄD
 
-Kontenery aplikacji działają **jako root**, a eksport ma `root_squash`, więc root
-z klienta NIE jest rootem na udziale. Żeby zapis działał, przypinamy cały ruch
-z tych hostów do jednego, nieuprzywilejowanego użytkownika — to bezpieczniejsze
-niż `no_root_squash`, bo nie oddaje roota.
+Kontenery aplikacji działają **jako root** (`uid=0`), a NFS domyślnie stosuje
+**`root_squash`**: root z klienta NIE jest rootem na udziale — ląduje jako
+`nobody`. Świeży dataset ma prawa `drwxrwx--- root root`, czyli **nic dla
+„innych"** — i dlatego zapis odbija się o `Permission denied`, mimo że `ls`
+w podzie pokazuje `root root`.
+
+To myli, bo `ls` pokazuje właściciela KATALOGU, a nie to, kim jest dla serwera
+proces, który próbuje pisać.
+
+Do wyboru dwa rozwiązania. Oba trzeba ustawić **przy eksporcie** (niżej), tu
+tylko przygotowujemy katalog.
+
+**A. Prościej — bez zakładania użytkownika.** Katalog zostaje `root:root 770`,
+a przy eksporcie ustawiamy `mapall_user: "root"`. To wyłącza squash **dla tego
+jednego udziału**. Zasięg jest wąski: eksportowany jest wyłącznie ten katalog,
+montują go tylko trzy węzły k8s, leży w nim jeden plik. Nic nie trzeba robić —
+świeży dataset ma już właściwe prawa.
+
+**B. Czyściej — dedykowany użytkownik.** Zakładasz w UI TrueNAS
+nieuprzywilejowanego użytkownika (np. `astrololo`), a potem:
 
 ```bash
-# użytkownik, na którego mapujemy (jeśli nie istnieje — utwórz w UI TrueNAS)
-sudo chown -R apps:apps /mnt/Tank1/astrololo-state
+sudo chown -R astrololo:astrololo /mnt/Tank1/astrololo-state
 sudo chmod 770 /mnt/Tank1/astrololo-state
 ```
 
-> Podstaw swojego użytkownika w miejsce `apps`. Sprawdzisz istniejących:
+i przy eksporcie podstawiasz go w `mapall_user`. Efekt ten sam, bez oddawania
+roota — kosztem jednego użytkownika więcej do pamiętania.
+
+> Istniejących użytkowników sprawdzisz przez:
 > `midclt call user.query | python3 -c "import sys,json;[print(u['uid'], u['username']) for u in json.load(sys.stdin)]"`
 
+> **Czego NIE robić:** `chmod 777`. Zadziała, ale uczyni katalog zapisywalnym dla
+> każdego lokalnego użytkownika NAS-a — a leżą tam hashe haseł, więc jest to plik
+> wrażliwszy niż same bazy Excela.
+
 ### Eksport NFS
 
 > **Najpierw sprawdź, czy udziału już nie ma.** `sharing.nfs.create` odmawia
@@ -80,8 +102,8 @@ midclt call sharing.nfs.create '{
   "hosts": ["192.168.1.73", "192.168.1.80", "192.168.1.81"],
   "enabled": true,
   "ro": false,
-  "mapall_user": "apps",
-  "mapall_group": "apps"
+  "mapall_user": "root",
+  "mapall_group": "root"
 }'
 ```
 
@@ -92,16 +114,18 @@ midclt call sharing.nfs.update <ID> '{
   "hosts": ["192.168.1.73", "192.168.1.80", "192.168.1.81"],
   "enabled": true,
   "ro": false,
-  "mapall_user": "apps",
-  "mapall_group": "apps"
+  "mapall_user": "root",
+  "mapall_group": "root"
 }'
 ```
 
+> Wybrałeś wariant B? Podstaw swojego użytkownika zamiast `root` w obu polach.
+
 | ustawienie | po co |
 |---|---|
 | `hosts` zawężone | te same trzy węzły k8s co w DAN-25 — nikt inny nie zamontuje |
 | `ro: false` | **musi być zapisywalny**, inaczej konta się nie zapiszą |
-| `mapall_user` | cały ruch pisze jako jeden nieuprzywilejowany użytkownik, niezależnie od UID w kontenerze |
+| `mapall_user` | cały ruch z tych hostów pisze jako JEDEN użytkownik, niezależnie od UID w kontenerze — bez tego `root_squash` zamienia roota z poda na `nobody`, który nie ma praw do katalogu |
 
 > Podstaw swoje adresy węzłów, jeśli się zmieniły. Aktualne:
 > `kubectl get nodes -o wide`
@@ -173,6 +197,32 @@ Oczekiwane: plik `accounts.json`.
 
 ---
 
+## Jeśli mimo wszystko `Permission denied`
+
+Trzy komendy, w tej kolejności:
+
+```bash
+kubectl -n astrololo exec deploy/presentation -- sh -c 'id; ls -ld /app/state; touch /app/state/proba && echo ZAPIS-OK || echo ZAPIS-NIE'
+```
+
+```bash
+midclt call sharing.nfs.query '[["path","=","/mnt/Tank1/astrololo-state"]]' \
+  | python3 -c "import sys,json;[print('ro:', s['ro'], '| mapall:', s.get('mapall_user'), '| hosts:', s['hosts']) for s in json.load(sys.stdin)]"
+```
+
+```bash
+sudo ls -ld /mnt/Tank1/astrololo-state
+```
+
+Zestaw, który DZIAŁA: kontener jako `uid=0(root)`, udział z `ro: false`
+i `mapall: root`, katalog `drwxrwx--- root root`.
+
+Po każdej zmianie eksportu: `midclt call service.restart nfs`, a potem
+`kubectl -n astrololo rollout restart deploy/presentation`. Sama zmiana
+konfiguracji nie przeładowuje eksportów.
+
+---
+
 ## Odkręcenie
 
 ```bash