docs: fsGroup wirkt bei SMB/NFS nicht — Rechte gehoeren in die mountOptions

Der Kommentar am fsGroup-Feld behauptete, Kubernetes ordne damit JEDES
gemountete Volume der Gruppe 1001 zu. Das stimmt nur fuer blockbasierten
Speicher.

Bei SMB/CIFS und NFS wird fsGroup ignoriert: diese Protokolle kennen keinen
per-Datei-Unix-Besitz, den der Knoten nachtraeglich aendern koennte. Ohne
uid/gid in den mountOptions erscheint dort alles als root:root, und der als
uid 1001 laufende Container scheitert bei jedem Upload mit EACCES — also
genau die Meldung "Die Datei konnte nicht gespeichert werden", ohne dass am
Deployment etwas falsch aussieht.

k8s/README.md bekommt dafuer einen eigenen Abschnitt: Diagnose im laufenden
Pod, die noetigen mountOptions (uid=1001, gid=1001 zusaetzlich zu
dir_mode/file_mode) und der Hinweis, dass Aenderungen daran erst beim
naechsten Einhaengen greifen, ein Rollout-Restart also dazugehoert.

Ebenfalls vermerkt: noperm umgeht die Rechtepruefung, statt den Besitz
richtigzustellen — es ersetzt uid/gid nicht.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>

k8s/05-app-deployment.yaml

@@ -51,8 +51,25 @@ spec:
       # Image bereits per chown gesetzten Besitzer von /app/uploads
       # vollstaendig, und der nicht-root laufende Container koennte trotzdem
       # keine Datei dort anlegen (EACCES bei jedem Admin-Upload). fsGroup
-      # sorgt dafuer, dass Kubernetes JEDES gemountete Volume zusaetzlich der
+      # sorgt dafuer, dass Kubernetes das gemountete Volume zusaetzlich der
       # Gruppe 1001 zuordnet und gruppen-schreibbar macht.
+      #
+      # ACHTUNG, GILT NICHT FUER JEDES BACKEND: fsGroup wirkt nur dort, wo
+      # Kubernetes den Besitz tatsaechlich setzen kann — also bei
+      # blockbasiertem Speicher. Bei SMB/CIFS und NFS wird es IGNORIERT, weil
+      # diese Protokolle keinen per-Datei-Unix-Besitz kennen, den der Knoten
+      # nachtraeglich aendern koennte. Dort gehoert die Zuordnung in die
+      # mountOptions des PersistentVolume:
+      #
+      #   mountOptions:
+      #     - uid=1001
+      #     - gid=1001
+      #     - dir_mode=0770
+      #     - file_mode=0660
+      #
+      # Ohne uid/gid erscheint bei SMB ALLES als root:root, und der Container
+      # scheitert trotz fsGroup mit EACCES. Siehe k8s/README.md, Abschnitt
+      # "Uploads lassen sich nicht speichern".
       securityContext:
         fsGroup: 1001
       containers: