6.10-RC2 NFS-Freigabe

[Da Do Ron]

Hi. Hat noch jemand auf 6.10 das Problem, dass die erstellten NFS-Freigaben von 6.9 nicht funktionieren? Ich kann nämlich nach einem Upgrade zu 6.10-RC2, von einer Buster-Server-VM, die auch auf dem selben Unraid-Server liegt, welche über NFS Zugriff auf einer Freigabe zum Array hat, nicht mehr an die benötigten Daten ran, weil die Verbindung nicht hergestellt werden kann. Auch ein Neustart der VM brachte keinen Erfolg. Nach anschließendem Downgrade auf 6.9.2 funktionierte es wieder.

 

Zur Info: Alles soweit kein Problem für mich, da es ein Testserver ist. Ich möchte mich nur im Vorfeld mit den neuen Funktionen vertraut machen. Habe ich etwas übersehen? Gibt es neue Protokolle oder ähnliches, die eine vorher erstellte Verbindung nicht ermöglichen? Oder ist das einfach nur ein Bug, der noch behoben wird?

 

LG  Da Do Ron

[blinddark]

Hi,

 

in 6.10RC2 wurde NFSV4 aktiviert. Sind die Freigaben auf privat gestellt? Ich habe bei mir noch einmal die Regeln erneuert und schon konnte ich von meinem PI auf den Server und auch Dateien Schreiben.

[Da Do Ron]

Danke für die schnelle Antwort. Ich habe, für den internen Betrieb, die Einstellungen auf Exportieren: "Ja" und Sicherheit: "Öffentlich". Musste damals schnell eingerichtet werden und ist nur für den internen Gebrauch.

Falls das nur noch auf "Privat" funktioniert, muss ich dann noch irgendwelche Benutzer/Passwortabfragen in der fstab der VM oder Raspi eintragen oder funktioniert das dann immer noch wie bisher? Meine bisheriger fstab-Eintrag für die NFS-Freigabe ist:

 

192.168.1.159:/mnt/user/data/vmdata /mnt/sharedfolders nfs defaults 0 0

 

Bin grad nicht am Rechner zum Testen, habe aber die Einträge im Kopf 🙂

 

LG  Da Do Ron

Edited December 13, 2021 by Da Do Ron

[Da Do Ron]

@blinddark. Ich habe die Regeln noch einmal überprüft. Es ist soweit egal, was ich einstelle. Auf 6.10RC2 bekomme ich derzeit keine NFS-Verbindung zum Array hin. Aus momentanen Zeitmangel werde ich mich am kommenden Wochenende damit befassen. Wenn noch jemand einen Tipp hat, werde ich das gern berücksichtigen. Falls ich das beheben kann, werde ich natürlich berichten.

 

LG  Da Do Ron

[Da Do Ron]

Ich bin dann doch schon etwas weiter gekommen. Die Unraid-NFS-Freigabe funktioniert mit "Öffentlich". Mit anderen Servern, auch mit der besagten VM kann ich per NFS darauf zugreifen. Nur die Nextcloud-Datenfreigabe funktioniert nicht mehr. Diese ist gesperrt. Ich kann mich schwach daran erinnern, dass ich das schon einmal, vor paar Jahren hatte. Ich muss mal meine Aufzeichnungen heraussuchen. Vielleicht finde ich was dazu.

[Da Do Ron]

Zur Info: Ich bin wieder etwas weiter gekommen, nur bisher ohne Erfolg 🙂 . NFS-Freigabe funktioniert. SMB-Freigabe funktioniert auch. Nur leider nicht, wenn man Nextcloud installiert und eine NFS-Freigabe als NC-Datenverzeichnis angibt. Ich beziehe mich hierbei auf die NFS-Freigabe zu einer Freigabe im Array und Nextcloud in einer Debian-Bullseye-Server-VM, welche unter Unraid installiert ist. Der handelsübliche Nextcloud-Docker unter Unraid funktioniert. Folgenden Fehler bekomme ich, wenn ich die erstellte Docker-Compose in der VM starte. Dabei ist die Fehlermeldung nur präsent, wenn ich als Datenverzeichnis die NFS-Freigabe zu und auf Unraid 10 wähle. Zuerst dachte ich, das liegt an meiner VM. Aber auf Unraid 9.6, mit der selben VM, funktioniert das Ganze.

 

root@debian-nc-wp:/home/dockervolumes/nextcloud# docker-compose up -d
Starting nextcloud_redis_1 ... done
Starting nextcloud_db_1    ... done
nextcloud_adminer_1 is up-to-date
Recreating nextcloud_app_1 ...

ERROR: for nextcloud_app_1  a bytes-like object is required, not 'str'

ERROR: for app  a bytes-like object is required, not 'str'
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/docker/api/client.py", line 261, in _raise_for_status
    response.raise_for_status()
  File "/usr/lib/python3/dist-packages/requests/models.py", line 943, in raise_for_status
    raise HTTPError(http_error_msg, response=self)
requests.exceptions.HTTPError: 500 Server Error: Internal Server Error for url: http+docker://localhost/v1.22/containers/6218d8840728663a214e217dfa477c31ebe689f54376bdd6efdc43eca525c1f6/start

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/compose/service.py", line 625, in start_container
    container.start()
  File "/usr/lib/python3/dist-packages/compose/container.py", line 241, in start
    return self.client.start(self.id, **options)
  File "/usr/lib/python3/dist-packages/docker/utils/decorators.py", line 19, in wrapped
    return f(self, resource_id, *args, **kwargs)
  File "/usr/lib/python3/dist-packages/docker/api/container.py", line 1095, in start
    self._raise_for_status(res)
  File "/usr/lib/python3/dist-packages/docker/api/client.py", line 263, in _raise_for_status
    raise create_api_error_from_http_exception(e)
  File "/usr/lib/python3/dist-packages/docker/errors.py", line 31, in create_api_error_from_http_exception
    raise cls(e, response=response, explanation=explanation)
docker.errors.APIError: 500 Server Error: Internal Server Error ("b"error while creating mount source path '/mnt/sharedfolders/NC/NC-Data': chown /mnt/sharedfolders/NC/NC-Data: operation not permitted"")

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/bin/docker-compose", line 11, in <module>
    load_entry_point('docker-compose==1.25.0', 'console_scripts', 'docker-compose')()
  File "/usr/lib/python3/dist-packages/compose/cli/main.py", line 72, in main
    command()
  File "/usr/lib/python3/dist-packages/compose/cli/main.py", line 128, in perform_command
    handler(command, command_options)
  File "/usr/lib/python3/dist-packages/compose/cli/main.py", line 1107, in up
    to_attach = up(False)
  File "/usr/lib/python3/dist-packages/compose/cli/main.py", line 1088, in up
    return self.project.up(
  File "/usr/lib/python3/dist-packages/compose/project.py", line 565, in up
    results, errors = parallel.parallel_execute(
  File "/usr/lib/python3/dist-packages/compose/parallel.py", line 112, in parallel_execute
    raise error_to_reraise
  File "/usr/lib/python3/dist-packages/compose/parallel.py", line 210, in producer
    result = func(obj)
  File "/usr/lib/python3/dist-packages/compose/project.py", line 548, in do
    return service.execute_convergence_plan(
  File "/usr/lib/python3/dist-packages/compose/service.py", line 561, in execute_convergence_plan
    return self._execute_convergence_recreate(
  File "/usr/lib/python3/dist-packages/compose/service.py", line 486, in _execute_convergence_recreate
    containers, errors = parallel_execute(
  File "/usr/lib/python3/dist-packages/compose/parallel.py", line 112, in parallel_execute
    raise error_to_reraise
  File "/usr/lib/python3/dist-packages/compose/parallel.py", line 210, in producer
    result = func(obj)
  File "/usr/lib/python3/dist-packages/compose/service.py", line 481, in recreate
    return self.recreate_container(
  File "/usr/lib/python3/dist-packages/compose/service.py", line 602, in recreate_container
    self.start_container(new_container)
  File "/usr/lib/python3/dist-packages/compose/service.py", line 627, in start_container
    if "driver failed programming external connectivity" in ex.explanation:
TypeError: a bytes-like object is required, not 'str'

 

Starte ich den up-d Befehl anschließend noch einmal, werden alle Docker in der Compose-Datei installiert und die Fehlermeldung erscheint nicht noch einmal. Aber dann kann Nextcloud nicht ins Datenverzeichnis schreiben und lässt sich nicht installieren. Noch schlimmer wird es, wenn ich einen eigenen Webserver für Nextcloud:fpm in der Compose-Datei mit verwende. Dann erscheint der Klassiker - Bad Gateway. Wohlbemerkt - das tritt nur unter Unraid 10 auf. Auf dem Unraid 9.6, welcher das identische Hard- und Software-Setup hat (außer die beiden Unraid-Versionen), passt alles, wie es sein sollte. 

 

Ich werde am Samstag weiter schauen, ob ich neue Erkenntnisse bekomme.

 

Nachtrag-1: Verwende ich als Nextcloud-Datenverzeichnis einen lokalen Ordner, direkt in der VM , funktioniert alles, wie es sein sollte.

Nachtrag-2: Verwende ich diese identische Docker-Compose direkt unter Unraid, funktioniert das auch. Aber das wollte ich eigentlich nicht realisieren, da es offiziell nicht unterstützt wird. Ich verwende lieber dieses Szenario in einer VM.

[Da Do Ron]

Ich kam dann doch schon heute dazu. Das Ergebnis meiner Tests ist ernüchternd. Was habe ich alles probiert? 

 

- Das NFS-Freigabeverzeichnis als Hauptordner angelegt - Man weiß ja nie

- Sämtliche Einstellungen der Unraid-NFS-Freigabe durchprobiert

- Einen weiteren Unraid-Server mit einer Testversion aufgesetzt

- eine weitere  VM mit Buster verwendet

- eine weitere VM mit Focal Fossa (Ubuntu LTS) verwendet

 

Ein externer Test steht noch aus. Ich werde noch einen Raspi mit Nextcloud aufsetzen und testen.

 

Nach jeder Änderung die Docker gestoppt, gelöscht und die angelegten Verzeichnisse per Hand gelöscht und neu angelegt. In allen Fällen das gleiche Ergebnis, inkl. dieser geposteten Fehlermeldung. Übrigens - Wordpress zeigte dieses Verhalten nicht. Da funktionierte alles. 

 

Abhilfe schaffte am Ende dann doch nur die Verwendung von Unraid 9.6.2.

 

Was mir jetzt grad eben noch einfällt, dass ich vielleicht eine Unraid-Freigabe direkt in der VM-Erstellung verwenden könnte. Dort sollte es definitiv funktionieren. Darauf verzichtete ich allerdings gern, weil die Geschwindigkeit zur Freigabe sehr bescheiden war. Ich kann mich noch leicht daran erinnern, dass ich einen Grund hatte, NFS zu verwenden. Ich werde diesen Versuch auch noch starten und die Geschwindigkeit testen. Vielleicht hat sich ja diesbezüglich bei den virtio-Treibern etwas getan. 

 

Das Hauptsystem bleibt vorerst auf 9.6.2 bestehen. Ich werde das Ganze aber im Auge behalten, wenn die 10'er Version ihren vollständigen Release erhält. Mit diesem Fehler, egal wo der nun herkommen mag, möchte ich mich auf dem Produktivsystem nicht herumärgern.

 

Bleibt noch die Frage, warum ich mir das Ganze mit einer VM und Docker-Compose antue 🙂 . Nun, die Geschwindigkeit des Zugriffes auf Nextcloud in Verbindung mit eigenem NginX-Webserver und Nextcloud:FPM ist einfach schneller, als es bei der normalen Docker-Version unter Unraid der Fall ist. Obwohl ich dort auch schon einen Redis-Cache als Docker hinzufügte und in Nextcloud eingebunden habe. Nextcloud hat es mir angetan. Ich teste immer wieder verschiedene Konstellationen auf verschiedenen Servern. Auch der Raspi bleibt da nicht verschont davon. Dabei ist es egal, ob nun nextcloud oder linuxserver/nextcloud oder MariaDb oder PostgreSQL. Ich nehme da alles mit. Einer Sache bin ich mir aber treu geblieben. Ich verwende auschließlich Docker. Ob nun einzeln oder als Docker-Compose-Script...

 

Das war's dann erst einmal zum Thema. Falls noch jemand eine Idee hat, nehme ich mich der Sache gern an. 

 

LG  Da Do Ron

[mgutt]

7 hours ago, Da Do Ron said:

Bleibt noch die Frage, warum ich mir das Ganze mit einer VM und Docker-Compose antue 🙂 . Nun, die Geschwindigkeit des Zugriffes auf Nextcloud in Verbindung mit eigenem NginX-Webserver und Nextcloud:FPM ist einfach schneller, als es bei der normalen Docker-Version unter Unraid der Fall ist. Obwohl ich dort auch schon einen Redis-Cache als Docker hinzufügte und in Nextcloud eingebunden habe.

Hattest du alle Pfade in /mnt/cache geändert? Schneller als direkt auf dem Host kann es nicht gehen. VMs laufen automatisch auf /mnt/cache, weshalb ich mir gut vorstellen kann, dass der Unterschied daher kommt.

[Da Do Ron]

Danke @mgutt für die Antwort.

Ich glaube, dass macht bei mir keinen Unterschied, ob ich cache oder user verwende. Ich habe für Docker und VM's, jeweils eine 1TB-SSD als Cache-only zugewiesen. Seit dieser Möglichkeit, mehrere Caches zu verwenden, habe ich das auch genutzt. Sag' mir bitte, wenn ich da falsch liege. Vielleicht passt mein mein Einhängebefehl nicht so richtig? Ich habe meine Unterlagen ausgekramt und hatte damals diesen Befehl, in meiner VM, in der fstab verwendet:

 

vmdata /mnt/sharedfolders 9p trans=virtio,version=9p2000.L,_netdev,rw 0 0

 

Danach habe ich erst mit SMB etwas getestet und entschied mich am Ende für NFS, was auch bis heute bei fast allen externen Rechnern und internen VM's präsent ist, außer auf zwei Windows-Rechner, die SMB als Zugriff zu den jeweiligen Freigaben verwenden.

 

Falls es nur am Befehl des Mountpointes liegt, lass' es mich wissen. 

[Da Do Ron]

Ich merke grad', ich habe etwas an Deiner Frage vorbei geantwortet. Sorry.

Also der erste Teil der Antwort passt zu Deiner Frage. Der Rest bezieht sich auf die direkte Freigabe. Vielleicht könntest Du etwas dazu sagen? 

[Da Do Ron]

17 hours ago, Da Do Ron said:

Was mir jetzt grad eben noch einfällt, dass ich vielleicht eine Unraid-Freigabe direkt in der VM-Erstellung verwenden könnte. Dort sollte es definitiv funktionieren. Darauf verzichtete ich allerdings gern, weil die Geschwindigkeit zur Freigabe sehr bescheiden war. Ich kann mich noch leicht daran erinnern, dass ich einen Grund hatte, NFS zu verwenden. Ich werde diesen Versuch auch noch starten und die Geschwindigkeit testen. Vielleicht hat sich ja diesbezüglich bei den virtio-Treibern etwas getan. 

 

Ich habe derweil die Übertragungsgeschwindigkeiten der beiden Sachen getestet. Also einmal die NFS-Verbindung und einmal die direkte Verbindung der VM zur Freigabe. Es hat sich dementsprechend noch nichts geändert, von damals zu heute. Ich verwendete für den Test 2 VM's, mit der selben Datei für den rsync-Befehl. Die Ergebnisse sprechen für sich.

 

Direkte Freigabe (Bullseye-VM1):

 

fstab-Eintrag: 

test /mnt/sharedfolders 9p trans=virtio,version=9p2000.L,_netdev,rw 0 0

 

Erreichte Werte:

root@nc-vm:~# rsync --info=progress2 /media/testfile /mnt/sharedfolders
  1,172,273,839 100%    8.82MB/s    0:02:06 (xfr#1, to-chk=0/1)

 

NFS-Freigabe (Bullseye-VM2):

 

fstab-Eintrag: 

192.168.1.58:/mnt/user/data/vmdata /mnt/sharedfolders nfs defaults 0 0

 

Erreichte Werte:

root@debian-nc-wp:/media# rsync --info=progress2 /media/testfile /mnt/sharedfolders
  1,172,273,839 100%  239.79MB/s    0:00:05 (xfr#1, to-chk=0/1)

 

Also führt kein Weg an NFS vorbei. Jedenfalls nicht, wenn ich es weiterhin so umsetzen möchte. Ich gehe aber davon aus, dass mein Problem in Version 10, bis zum richtigen Release, noch verschwindet. Was die Ursache ist, kann ich nicht bestimmend sagen. Python-Probleme oder Probleme mit dem Anlegen der Benutzer-Schreibrechte von Nextcloud auf die NFS-Freigabe für den Datenordner selbst, ich weiß es nicht. Eines ist sicher. Auf Unraid9.6 funktioniert es noch. Auch nach einem Downgrade zurück zur Version 9.6. funktioniert es wieder, ohne weitere Änderungen gemacht zu haben.

 

Am Ende noch eine Sache. Kann mir jemand die Frage beantworten, ob der fstab-Eintrag meiner Direkt-Freigabe richtig ist? Oder lege ich mir da selbst Fallstricke, weil vielleicht die eingetragenen Werte nicht passend sind? Es geht um diesen fstab-Eintrag für das Mounten der Freigabe, wenn diese in der VM direkt als Unraid-Verzeichnis verwendet wird:

 

test /mnt/sharedfolders 9p trans=virtio,version=9p2000.L,_netdev,rw 0 0

 

LG  Da Do Ron

[mgutt]

Die 9p virtio Geschichte ist allgemein lahm. Das ist aber bekannt und niemand nutzt das. Wenn dann nur SMB oder NFS.

 

3 hours ago, Da Do Ron said:

Ich habe für Docker und VM's, jeweils eine 1TB-SSD als Cache-only zugewiesen. Seit dieser Möglichkeit, mehrere Caches zu verwenden, habe ich das auch genutzt. Sag' mir bitte, wenn ich da falsch liege. Vielleicht passt mein mein Einhängebefehl nicht so richtig?

Auch wenn man SSDs hat ist /mnt/user langsamer als /mnt/cache.

 

/mnt/user Pfade laufen durch den FUSE Prozess, während /mnt/diskX bzw /mnt/cache Pfade direkt auf den Datenträger zugreifen.

 

Deswegen sehen meine Docker Einstellungen so aus:

 

Und alle meine Container greifen direkt auf /mnt/cache zu.

 

[Da Do Ron]

19 minutes ago, mgutt said:

Auch wenn man SSDs hat ist /mnt/user langsamer als /mnt/cache.

 

Das ist ja mal 'ne Info. Vielen Dank dafür. Davon ausgehend, dass das stimmt, werde ich natürlich umstellen. Auf die Tatsache, wie Du es beschreibst, wäre ich nicht gekommen. 33 aktive Docker müssen nun angepasst werden 🙂 .

 

Danke nochmals.

[mgutt]

Check vorher noch über Shares > appdata Ordner Symbol > LOCATION, dass wirklich alle Containerdaten auf dem Cache liegen. Ansonsten müssen die erst mit dem Mover verschoben werden. 

[Da Do Ron]

/mnt/cache/docker funktioniert nicht. Das wäre dann bestimmt /mnt/cache/docker/docker.img

 

 

Edited December 18, 2021 by Da Do Ron

[Da Do Ron]

6 minutes ago, mgutt said:

Check vorher noch über Shares > appdata Ordner Symbol > LOCATION, dass wirklich alle Containerdaten auf dem Cache liegen. Ansonsten müssen die erst mit dem Mover verschoben werden. 

 

Habe ich schon gemacht. Alles auf Cache liegend.

[mgutt]

26 minutes ago, Da Do Ron said:

/mnt/cache/docker funktioniert nicht

Türlich. Gibt ja auch die Ordner-Installation und nicht nur Image. Dadurch fällt der Overhead vom Image weg und Docker belegt auch viel weniger Speicherplatz.

 

Dann muss man aber kurz über Apps > Previous Apps die Container wiederherstellen, da er dann die Pakete bei runterladen muss.

[Da Do Ron]

Davon habe ich schon mal gehört, bin aber nie darauf eingegangen.

Ich habe nun die beiden vorher angelegten docker.img rüber kopiert ins /mnt/cache/docker-Verzeichnis. Somit waren alle Docker sofort wieder da. Ich stelle eben die letzte Docker auf /mnt/cache/appdata/... um. Was mir jetzt schon auffällt, dass der Zugriff bei bestimmten Docker mit verfügbarem Web-Interface, etwas schneller geht. Oder ist das jetzt die obligatorische Einbildung, dass es einfach schneller laufen muss? 

Was aber keine Einbildung ist, dass die Prozessorlast im Ruhemodus, also wenn die Docker zwar gestartet sind, aber grad nichts zu tun haben, 4 Prozent herunter ging. 

[Da Do Ron]

Bin nun fertig. Was soll ich sagen. Ich habe doch schon etwas Tränen in den Augen 🙂 . Hätte ich nie und nimmer gedacht, dass man mit so einer geringfügigen Änderung, spürbare Erfolge erzielen kann. Nextcloud RENNT. Und das spürbar. Wordpress übrigens auch. Bei Grafana, Emby, Pihole, phpipam und Calibre-Web habe ich ebenfalls das Gefühl, dass die etwas schneller aufbauen.

Das Wichtigste für mich ist und war Nextcloud. Somit könnte ich mich nun von meiner VM verabschieden. Da die Nacht aber erst anfängt, stelle ich noch paar Tests gegenüber. Aber ich bin eigentlich jetzt schon mehr als zufrieden. 

 

Bleibt noch das Problem, weshalb ich diesen Thread eröffnete. Aber das scheint mich, jedenfalls für den internen Unraid-Betrieb, wohl gerade nicht mehr zu interessieren, da ich durch Zufall und Deiner Hilfe eine andere Lösung gefunden habe. Da das Problem aber auch auftritt, wenn man von externen Geräten auf NFS zugreift, bleibe ich da trotzdem dran.

[mgutt]

1 hour ago, Da Do Ron said:

Was aber keine Einbildung ist, dass die Prozessorlast im Ruhemodus, also wenn die Docker zwar gestartet sind, aber grad nichts zu tun haben, 4 Prozent herunter ging. 

Falls du die erweiterte Ansicht bei den Containern aktiviert hast, dann deaktiviere die. Spart auch noch mal 1 bis 2% Last. Das Monitoring läuft nämlich 24/7, egal ob die WebUI offen ist oder nicht.

 

1 hour ago, Da Do Ron said:

Nextcloud RENNT. Und das spürbar.

Jo. Immer wenn eine SQL-Datenbank im Spiel ist, ist das ein Unterschied wie Tag und Nacht. Für viele kleine Zugriffe ist FUSE leider der letzte Schrott.

 

Bei der Umstellung auf /mnt/cache muss man übrigens folgendes beachten:

- geht der Cache kaputt, geht kein Container mehr. Wenn man dann zB appdata aus einem Backup auf dem Array wiederherstellt, wird auch nichts laufen bis man alle Container wieder auf /mnt/user zurückgestellt hat. 

- läuft der Cache voll, dann schmieren evtl die Container ab. Aus dem Grund stellt man am besten einen Free Min Space auf dem Cache Pool ein. Auf den Poolnamen klicken und dann da einen Wert eintragen. Ich empfehle mind 10GB. Ich habe sogar 100GB eingestellt, da ich manchmal bis zu drei Blu-Rays parallel rippe und es zu einem Fehler kommt, wenn die parallel den Cache voll schreiben. So ist mir der Cache noch nie vollgelaufen bzw aus Sicht der Shares ist er dann voll und weitere Uploads gehen direkt ins Array und die Container haben noch genug Platz und laufen fehlerfrei weiter.

 

 

Ich habe gerade mal aus Interesse die Belegung ermittelt. Also /docker zieht keine 6GB und normal ist das Image ja alleine 20GB groß:

du -hs /mnt/cache/*
299G    /mnt/cache/Movie
283G    /mnt/cache/Music
159G    /mnt/cache/appdata
5.6G    /mnt/cache/docker
32G     /mnt/cache/domains
1.1G    /mnt/cache/system
492G    /mnt/cache/web

 

[Da Do Ron]

1 hour ago, mgutt said:

- läuft der Cache voll, dann schmieren evtl die Container ab.

 

Ein dritter Cache wäre wohl etwas übertrieben, aber in diesem Fall meine erste Überlegung.

 

Nun, ich setze tägliche rsync-Backups zu einem ext. Backup-Server. Das User Script in Unraid ist da bestens geeignet. Wie sich die Umstellung, bei einem Ausfall des Caches, bemerkbar macht, werde ich auf alle Fälle noch testen. Wozu hat man einen Test-Server 🙂 . Ich werde alle Tipps berücksichtigen und in meinen Überlegungen einbeziehen.

 

So sieht das bei mir aus. 50GB Free Min Space hatte ich irgendwann schon einmal eingestellt.

 

du -hs /mnt/cache/*
45G     /mnt/cache/appdata
1.6G    /mnt/cache/data
68G     /mnt/cache/docker
1.8G    /mnt/cache/isos
5.1G    /mnt/cache/lancache
1.3G    /mnt/cache/nextclouddata-new
0       /mnt/cache/nextcloudwebdata
0       /mnt/cache/save
69G     /mnt/cache/system

 

Edited December 18, 2021 by Da Do Ron

[mgutt]

68GB nur für Docker Pakete? Welcher hat denn so große Installationsdateien?! 

[Da Do Ron]

1 hour ago, mgutt said:

Falls du die erweiterte Ansicht bei den Containern aktiviert hast, dann deaktiviere die.

 

Das wusste ich auch noch nicht. Allerdings muss erst schauen, wo ich das deaktiviere. Immer wenn die herausnehme, ist die beim nächsten Öffnen wieder drin.

[Da Do Ron]

1 minute ago, mgutt said:

68GB nur für Docker Pakete? Welcher hat denn so große Installationsdateien?! 

 

Wahrscheinlich mein eigener. Schätze ich mal. Ich habe vor paar Wochen ein Image erstellt und von Euch freigeben lassen. Ubuntu-XFCE-novnc. 

[Da Do Ron]

Ich habe dann doch noch eine Frage. Wenn die Docker nun auf Cache liegen - macht dann der Mover etwas damit? Oder könnte ich die Dockersachen unter /mnt/user/appdata/... löschen? Also nur die spezifischen Dockersachen, die ich vorhin geändert habe. Einige Sachen von einigen Dockern liegen bewusst auf /mnt/user/appdata. Obwohl die ausgewählten Sachen dort eigentlich auch raus können und auf einer Array-Freigabe gepackt werden können. Ich habe das aber erst beim Schreiben gemerkt, dass eigentlich /mnt/user/appdata kompett raus kann.

Edited December 18, 2021 by Da Do Ron