docs: InfluxDB on 1.11.8 after the full-access repair

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

config/skills/grafana.md

@@ -28,16 +28,16 @@ brak
 ## Powrót
 `rollback.sh grafana --from <backup_dir> --service grafana`.
 
-## InfluxDB 1.8 → 1.11 (stan VM103: 2026-09-23)
-Aktualnie `influxdb:1.8.10` (działa jako root). Dane: `/srv/appdata/grafana/influxdb` → `/var/lib/influxdb`, ~21 GB, właściciel `1000:1000` (mariuszp), tryb `700`. Cel: stabilne `1.11.x` (wzorzec `^1\.11\.[0-9]+$`), bez przejścia do 2.x/3.x. Port `192.168.0.139:18086`, pisze do niej Telegraf.
+## InfluxDB 1.x (stan VM103: 2026-09-23)
+Aktualnie `influxdb:1.11.8` z `user: "1000:1000"` w compose (aktualizacja z 1.8.10 zrobiona 2026-09-23, run `d42540b6`). Dane: `/srv/appdata/grafana/influxdb` → `/var/lib/influxdb`, ~21 GB, właściciel `1000:1000` (mariuszp), tryb `700`. Cel: stabilne `1.11.x` (wzorzec `^1\.11\.[0-9]+$`), bez przejścia do 2.x/3.x. Port `192.168.0.139:18086`, pisze do niej Telegraf.
 Źródła: [release notes v1](https://docs.influxdata.com/influxdb/v1/about_the_project/release-notes/), [upgrade 1.11](https://docs.influxdata.com/influxdb/v1/administration/upgrading/), [backup/restore](https://docs.influxdata.com/influxdb/v1/administration/backup_and_restore/).
 
 Kopia: codzienny vzdump VM103 (02:00) obejmuje oba dyski, także ten z `/srv/appdata`; workflow sprawdza jego świeżość i kopiuje compose przed zmianą. Dodatkowa kopia `influxd backup -portable` nie jest wymagana — jej brak to nie powód do STOP.
 
 Znany problem (test 2026-09-23): obraz `1.11.x` działa jako użytkownik `influxdb` (uid 1500) i nie zmienia właściciela danych, więc wpada w pętlę restartów z `mkdir /var/lib/influxdb/meta: permission denied`, zanim dotknie danych.
-Naprawa: w `compose.yaml` dodaj usłudze `influxdb` linię `user: "1000:1000"` (właściciel katalogu danych; potwierdź `hl run influxdb --user root -- stat -c %u:%g /var/lib/influxdb`), potem `hl write` i `hl up influxdb`. Nie rób `chown -R` na danych i nie uruchamiaj jako root. Zmiana `user` przechodzi tylko w sesji z pełnym dostępem: w zwykłej sesji nie szukaj obejść, od razu odpowiedz `gave_up` z tym opisem, żeby właściciel włączył „Repair with full access”.
+Naprawa (zrobiona): `user: "1000:1000"` w compose (właściciel katalogu danych), a pliki pozostawione przez 1.8.10 jako root dostały właściciela punktowo: `hl run influxdb --user root -- find /var/lib/influxdb -not -user 1000 -exec chown 1000:1000 {} +`, potem `hl restart influxdb`. Bez tego część shardów (`fields.idx.tmp`) zwraca 500 przy zapisie. Nie rób `chown -R` całego drzewa i nie uruchamiaj jako root. Przy kolejnych aktualizacjach 1.11.x zostaw `user:` bez zmian. Zmiana `user` przechodzi tylko w sesji z pełnym dostępem: w zwykłej sesji nie szukaj obejść, od razu odpowiedz `gave_up` z tym opisem, żeby właściciel włączył „Repair with full access”.
 Nie zmieniaj typu indeksu ani innej konfiguracji.
 
 Odbiór: kontener `running` na przypiętym obrazie, bez restartów; `/ping` → 204 z nagłówkiem `X-Influxdb-Version: 1.11.x`; `hl exec influxdb -- influx -execute 'SHOW DATABASES'` pokazuje m.in. `telegraf`; `hl exec influxdb -- influx -database telegraf -execute 'SHOW MEASUREMENTS LIMIT 5'` zwraca serie (stare dane są czytelne); w logach brak błędów TSM/WAL/shard. Nowe punkty od Telegrafa po restarcie potwierdzają zapis. Panele Grafany sprawdza właściciel.
 STOP: kandydat poza `1.11.x`; po starcie 1.11 bazy lub serie znikają albo logi pokazują błędy odczytu shardów/TSM — wtedy nie naprawiaj na siłę, tylko opisz i zostaw decyzję o rollbacku właścicielowi.
-Powrót: rollback przywraca compose z `1.8.10`; ten obraz działa jako root, więc `user:` ani właściciel plików mu nie przeszkadzają. Gdyby po rollbacku 1.8.10 nie czytał danych zapisanych przez 1.11, ratunkiem jest vzdump.
+Powrót: rollback przywraca compose sprzed aktualizacji; do `1.8.10` (root) właściciel plików nie przeszkadza. Gdyby po rollbacku 1.8.10 nie czytał danych zapisanych przez 1.11, ratunkiem jest vzdump.