gitea/deploy
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

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

Browse Source 
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>
This commit is contained in:
migatu
2026-08-07 18:48:44 +02:00
parent aff4de4e49
commit ddec1ee5a7
1 changed files with 58 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files
astrololo/README-stan-prezentacji.md
+58 -2
View File
@@ -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` —
wróć do praw katalogu i `mapall_user` w kroku 1.
Musi wypisać **`ZAPIS DZIAŁA`**.
| 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ł.
---