fix(deploy): systemd-Unit ohne eigenen Mount-Namespace

ProtectSystem/PrivateTmp/ProtectControlGroups erzeugen einen Namespace als
slave; Mounts blieben dort gefangen (auf der Test-VM nachgewiesen) und
verschwanden bei jedem Neustart. MountFlags=shared hilft nicht. Nur noch
Härtungen ohne Namespace.

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

deploy/netmover.service

@@ -27,18 +27,17 @@ RuntimeDirectory=netmover
 RuntimeDirectoryMode=0700
 
 # Härtung, soweit mit Mounten vereinbar.
-# Die Optionen unten erzeugen einen eigenen Mount-Namespace für den Dienst.
+# WICHTIG: Keine Optionen, die einen eigenen Mount-Namespace erzeugen
-# MountFlags=shared sorgt dafür, dass Mounts unter /mnt/netmover trotzdem im
+# (ProtectSystem=, ProtectHome=, PrivateTmp=, ProtectControlGroups=,
-# System sichtbar sind (prüfen mit: findmnt -R /mnt/netmover).
+# ReadOnlyPaths=, BindPaths= …). Sonst landen die Mounts im Namespace des
-MountFlags=shared
+# Dienstes: das System und andere Programme (Paperless!) sähen sie nicht, und
-# /usr, /boot und /etc schreibgeschützt; /mnt, /opt, /srv, /var bleiben schreibbar
+# jeder Neustart des Dienstes würde sie verwerfen. MountFlags=shared hilft dagegen
-# (lokale Ziele wie /opt/paperless/consume funktionieren also).
+# nicht – systemd setzt den Namespace als „slave“ auf, Mounts fließen nur hinein.
-ProtectSystem=full
+# Auf dem Testsystem nachgewiesen; prüfen mit: findmnt -l | grep /mnt/netmover
-PrivateTmp=yes
 NoNewPrivileges=yes
-ProtectControlGroups=yes
 LockPersonality=yes
 RestrictRealtime=yes
+RestrictSUIDSGID=yes
 UMask=0022
 
 [Install]