docs(nfs): runbook radzi sobie z udziałem, który już istnieje

Instrukcja kazała wołać sharing.nfs.create, co przy istniejącym udziale odbija się
komunikatem „Export conflict" — i zostawia człowieka bez następnego kroku.
Teraz najpierw query, potem create ALBO update, zależnie od wyniku.

Dołożony sprawdzian `exportfs -v`: zapisana konfiguracja udziału i stan eksportu
to dwie różne rzeczy, a „access denied by server" przy poprawnej liście hostów
najczęściej znaczy właśnie, że usługa nie przeładowała eksportów.

Tabela objawów rozróżnia cztery przypadki, które łatwo pomylić: brak praw, brak
wpuszczenia przez serwer, brak katalogu i negocjację wersji NFS.

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

astrololo/README-stan-prezentacji.md

@@ -62,11 +62,35 @@ sudo chmod 770 /mnt/Tank1/astrololo-state
 
 ### Eksport NFS
 
+> **Najpierw sprawdź, czy udziału już nie ma.** `sharing.nfs.create` odmawia
+> z komunikatem `Export conflict`, jeśli ten sam katalog jest już eksportowany —
+> wtedy trzeba go **zaktualizować**, nie tworzyć.
+
+```bash
+midclt call sharing.nfs.query '[["path","=","/mnt/Tank1/astrololo-state"]]' \
+  | python3 -m json.tool
+```
+
+**Pusta lista `[]`** — udziału nie ma, twórz:
+
 ```bash
 midclt call sharing.nfs.create '{
   "path": "/mnt/Tank1/astrololo-state",
   "comment": "astrololo — stan prezentacji (konta PRE-27)",
   "hosts": ["192.168.1.73", "192.168.1.80", "192.168.1.81"],
+  "enabled": true,
+  "ro": false,
+  "mapall_user": "apps",
+  "mapall_group": "apps"
+}'
+```
+
+**Coś zwróciło** — weź `id` z wyniku i zaktualizuj (podstaw `<ID>`):
+
+```bash
+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"
@@ -84,6 +108,28 @@ midclt call sharing.nfs.create '{
 
 ---
 
+### Sprawdź, co serwer FAKTYCZNIE eksportuje
+
+Konfiguracja udziału i stan eksportu to **dwie różne rzeczy**: zapisana
+konfiguracja nie znaczy, że usługa ją przeładowała. To jest prawda:
+
+```bash
+sudo exportfs -v | grep -A1 astrololo
+```
+
+Muszą być **dwa** wpisy: `/mnt/Tank1/astrololo` (z `ro`) oraz
+`/mnt/Tank1/astrololo-state` (z `rw`), oba z listą trzech węzłów.
+
+Jeśli `astrololo-state` **nie ma na liście**, mimo że `sharing.nfs.query` go
+pokazuje — usługa nie przeładowała eksportów:
+
+```bash
+midclt call service.restart nfs
+sudo exportfs -v | grep astrololo-state
+```
+
+---
+
 ## Krok 2 — sprawdź z węzła, ZANIM wdrożysz
 
 To jest ten test, którego zabrakło za pierwszym razem:
@@ -94,8 +140,18 @@ ssh 192.168.1.73 'sudo mount -t nfs 192.168.1.34:/mnt/Tank1/astrololo-state /mnt
   && sudo rm /mnt/test/proba; sudo umount /mnt/test'
 ```
 
-Musi wypisać **`ZAPIS DZIAŁA`**. Jeśli zamiast tego widzisz `Permission denied` —
+Musi wypisać **`ZAPIS DZIAŁA`**.
-wróć do praw katalogu i `mapall_user` w kroku 1.
+
+| co widzisz | co to znaczy |
+|---|---|
+| `Permission denied` przy `touch` | montowanie działa, brakuje praw — wróć do właściciela katalogu i `mapall_user` |
+| `access denied by server while mounting` | serwer nie wpuszcza w ogóle: sprawdź `exportfs -v` (czy eksport istnieje i przeładowany), `enabled: true` w udziale oraz czy adres węzła jest na liście `hosts` |
+| `No such file or directory` | katalog `/mnt/Tank1/astrololo-state` nie istnieje na NAS-ie |
+| montuje się tylko z `-o vers=3` | negocjacja wersji: dopisz `mountOptions` w manifeście albo włącz NFSv4 w `midclt call nfs.config` |
+
+Adresy węzłów sprawdzisz przez `kubectl get nodes -o wide` — jeśli któryś się
+zmienił od czasu DAN-25, lista `hosts` jest nieaktualna i to wystarczy, żeby
+serwer odmówił.
 
 ---