fix(restore): nextcloud-test disable check_data_directory_permissions

Erster Lauf am 2026-06-03 lief sauber durch alle Phasen (Borg-Extract,
pg_restore, Container alle gesund), schlug aber im HTTP-Smoke mit 503 fehl.
Ursache (aus dem preserved /mnt/user/backups/restore-lab/_failed/...):
- OC_Util.php:486 prueft die Permissions der data-Dir
- Skript hatte chmod -R a+rwX gesetzt (0777, letzte Stelle 7)
- Nextcloud versucht selbst chmod(0770) als www-data im Container
- Unraids shfs/FUSE lehnt chmod von Non-Root ab
- Nextcloud meldet "data directory readable by other people" -> 503

Fix: in der gepatchten config.php zusaetzlich
'check_data_directory_permissions' => false setzen. Nextcloud bietet
das in OC_Util:480 explizit als Opt-out an, fuer den isolierten Smoke
mit Wegwerf-Daten ist das vertretbar (kein Public, kein Traefik).
Produktiv bleibt der Check natuerlich an.

Patching erfolgt im bestehenden PHP-Injection-Block; idempotent (laeuft
keine Aenderung wenn beide Keys schon im config.php sind). Fallback-
sed-Pfad fuer Hosts ohne php ebenfalls erweitert.

ops/restore-tests/nextcloud-restore-test.sh

@@ -155,16 +155,30 @@ if [ -f "$CONFIG_PHP" ]; then
   # Wir ersetzen nur den Host-Wert innerhalb des redis-Blocks.
   sed -i "s|'host' => 'nextcloud-redis'|'host' => 'restoretest-nextcloud-redis'|g" "$CONFIG_PHP"
 
-  # trusted_domains: 127.0.0.1 hinzufuegen, damit der Smoke-Endpunkt akzeptiert wird.
+  # Zwei Patches in der config.php, beides per PHP-Code-Injection am Ende:
-  # Nextcloud prueft trusted_domains und blockt sonst mit "Access through untrusted domain" (503).
+  #
-  # Wir fuegen per PHP-Code-Injection am Ende der config eine zweite trusted_domain hinzu.
+  # 1. trusted_domains: 127.0.0.1 hinzufuegen, damit der Smoke-Endpunkt
-  # Das ist robuster als den Array-Block per sed zu finden.
+  #    akzeptiert wird. Nextcloud prueft trusted_domains und blockt sonst
+  #    mit "Access through untrusted domain" (503).
+  #
+  # 2. check_data_directory_permissions: false. Hintergrund: Nextcloud
+  #    (OC_Util::checkDataDirectoryPermissions) prueft beim HTTP-Request, ob
+  #    die data-Dir-Permissions in der letzten Stelle 0 sind. Falls nicht,
+  #    versucht es als www-data ein chmod(0770). Auf Unraid (shfs/FUSE)
+  #    lehnt das Filesystem chmod von Non-Root ab, also kann der Container
+  #    das nie korrigieren -> Nextcloud meldet "data directory readable by
+  #    other people" -> HTTP 503. Im isolierten Smoke-Kontext (Wegwerf-
+  #    Daten, kein Public, kein Traefik) ist das Aushebeln dieses Checks
+  #    sauber dokumentiert vorgesehen. Produktiv bleibt der Check an.
   php -r "
     \$f = '$CONFIG_PHP';
     \$c = file_get_contents(\$f);
-    if (strpos(\$c, \"'127.0.0.1'\") === false) {
+    if (strpos(\$c, \"'127.0.0.1'\") === false || strpos(\$c, 'check_data_directory_permissions') === false) {
       include \$f;
-      \$CONFIG['trusted_domains'][] = '127.0.0.1';
+      if (!in_array('127.0.0.1', \$CONFIG['trusted_domains'])) {
+        \$CONFIG['trusted_domains'][] = '127.0.0.1';
+      }
+      \$CONFIG['check_data_directory_permissions'] = false;
       \$out = '<?php' . PHP_EOL . '\$CONFIG = ' . var_export(\$CONFIG, true) . ';' . PHP_EOL;
       file_put_contents(\$f, \$out);
     }
@@ -173,6 +187,9 @@ if [ -f "$CONFIG_PHP" ]; then
     if ! grep -q "127.0.0.1" "$CONFIG_PHP"; then
       sed -i "/'trusted_domains'/,/^  )/s|^  )|    99 => '127.0.0.1',\n  )|" "$CONFIG_PHP" || true
     fi
+    if ! grep -q "check_data_directory_permissions" "$CONFIG_PHP"; then
+      sed -i "s|^);|  'check_data_directory_permissions' => false,\n);|" "$CONFIG_PHP" || true
+    fi
   }
 
   config_patched="ok"