Der in der Dokumentation empfohlene Weg besteht ja darin, die Home-Verzeichnisse auf dem Server als externe Storages in der Nextcloud verfügbar zu machen.
In der Konsequenz haben die Benutzer drei verschiedene Speicherorte für ihre Dateien, nämlich
das lokale Home-Verzeichnis,
das Home-Verzeichnis auf dem Server und
ihr benutzerspezifisches Verzeichnis in der Nextcloud.
Ich finde es gar nicht so leicht, Empfehlungen dafür abzugeben, was im Home-Verzeichnis auf dem Server und was direkt in der Nextcloud gespeichert werden soll.
Nun hatte ich die wilde Idee, auf dem Debian-Client den Nextcloud-Sync-Client zu installieren und als lokales Nextcloud-Verzeichnis direkt das Home-Verzeichnis auf dem Server zu wählen.
Wäre das an einer Schule mit knapp 900 Schülern, drei Computerräumen und diversen Laptops praktikabel, oder ginge das Netzwerk vermutlich hoffnungslos in die Knie?
generell stellt sich halt die Frage, ob die Leute alle Konfigurationsdateien und temporäre Dateien von Anwendungen in ihrer NextCloud-Umgebung benötigen und ggf. mit langen Synchronisationszeiten leben können.
Wir haben hier mehrere Anwendungen, die im Worst-Case jeweils bis zu 1 Gigabyte an Daten im Nutzerprofil ablegen, die aber größtenteils Caches, Extensions und Konfiguration sind. Das sind aber alles nicht die eigentlichen Dateien, die der Nutzer im Programm über „Datei öffnen“ laden wollen würde. Es gibt auch Anwendungen, welche dateibasierte Datenbanken verwenden, z. B. betrifft das mittlerweile alle Browser mit SQLite, die allergisch darauf reagieren, wenn diese sich zur Laufzeit ändern. Entsprechend sperren diese Anwendungen solche Dateien mit Locking-Mechanismen, was dann wieder die Synchronisation verhindern kann. Im Worst-Case führt das zu Blockaden oder zumindest zu Verzögerungen der Synchronisation durch Timeouts und Wiederholungsversuche.
In deinem Szenario würde ich versuchen das Home-Verzeichnis auf dem Server als lokales Home-Verzeichnis einzubinden und ein Unterverzeichnis darunter via NextCloud bereitzustellen.