Den Standard AppData Pfad habe ich ebenfalls angepasst.  
Mein vorgehen mag ungewöhnlich sein, ist sicher nicht aktuellster Stand der Dinge.. aber ich hab mir wirklich was dabei gedacht 😂 (Unraid sicherlich auch bei ihren Einstellungen :D) 

stand jetzt ist alles auf einem Share, alles zusammen, auch Appdata. Ich hoffe das passt einfach für die Zukunft!

Aber herzlichen Dank für den Hinweis.

 

Bin gespannt ob ich heute mit mgutt auf eine Lösung meines Write Problems komme, und vor allem ob es ein Fehler von mir ist …

Sollte aber nicht der Fall sein wenn du auf "Add Container" klickst auf der Docker seite weil dort dein individuelles template gespeichert ist und wiederhergestellt wird.

...wie oben schon geschrieben, steht mein template leider, bis auf einen der 5 kritischen, auf ":latest" [emoji1787]

Gesendet von meinem SM-G960F mit Tapatalk

37 minutes ago, Ford Prefect said:

...wie oben schon geschrieben, steht mein template leider, bis auf einen der 5 kritischen, auf ":latest"

Das sollte aber nicht sein, wenn es dein template ist dann steht auch der tag drin, kann natürlich sein wenn es aus der CA App ist das wenn der maintainer das template updated es wieder zurückgesetzt wird, deswegen änder ich gleich alle templates ab das sowas bei mir nicht passiert. 😅

Ich habe mal die RAM-Disk in die go-file eingetragen. Müsste Sie nicht mit einem df -h angzeigt werden?

 

root@Tower:~# df -h
Filesystem      Size  Used Avail Use% Mounted on
rootfs           16G  749M   15G   5% /
devtmpfs         16G     0   16G   0% /dev
tmpfs            16G     0   16G   0% /dev/shm
cgroup_root     8.0M     0  8.0M   0% /sys/fs/cgroup
tmpfs           128M  288K  128M   1% /var/log
/dev/sda1        15G  301M   15G   2% /boot
overlay          16G  749M   15G   5% /lib/modules
overlay          16G  749M   15G   5% /lib/firmware
tmpfs           1.0M     0  1.0M   0% /mnt/disks
tmpfs           1.0M     0  1.0M   0% /mnt/remotes
/dev/md1         13T  2.6T   11T  21% /mnt/disk1
/dev/md2        1.9T  415G  1.5T  23% /mnt/disk2
/dev/nvme0n1p1  466G   14M  466G   1% /mnt/cache_1_nvme
/dev/sdc1       233G  161G   72G  70% /mnt/cache_raid
/dev/sdb1       466G   63G  403G  14% /mnt/cache_ssd
shfs             15T  3.0T   12T  21% /mnt/user0
shfs             15T  3.0T   12T  21% /mnt/user
/dev/loop2      1.0G  4.6M  904M   1% /etc/libvirt

Irgendwie hab ich alles gemacht hab aber dennoch schreibzugriffe auf mein ssd_raid 😞

 

 

Edited September 9, 20214 yr by guybrush2012

3 hours ago, ich777 said:

Sollte aber nicht der Fall sein wenn du auf "Add Container" klickst auf der Docker seite weil dort dein individuelles template gespeichert ist und wiederhergestellt wird.

Wenn er von img auf Pfad wechselt, dann wird alles neu installiert. Also darauf bezieht er sich ja meine ich.

12 minutes ago, mgutt said:

Wenn er von img auf Pfad wechselt, dann wird alles neu installiert. Also darauf bezieht er sich ja meine ich.

Genau aber der tag bleibt auch im user template gespeichert wenn er vom user geändert wurde (außer wie oben erwähnt der template maintainer ändert was dann wird das template auch geändert) und er hat doch gemeint das er nicht latest will.

6 minutes ago, ich777 said:

Genau aber der tag bleibt auch im user template gespeichert

Ich habe das so verstanden, dass er keinen tag nutzt = latest und die ganze Zeit die Meldung für ein Update bewusst ignoriert, damit er bei der alten Version bleibt. Daher schlug ich ja vor, dass er einen tag setzt, damit er auf die Art die alte Version des Containers erzwingt.

2 hours ago, guybrush2012 said:

Ich habe mal die RAM-Disk in die go-file eingetragen. Müsste Sie nicht mit einem df -h angzeigt werden?

 

Hast du den Server auch neu gestartet?

Bei mir wird folgendes Angezeigt: (letzter Eintrag ist der Relevante)

 

Filesystem      Size  Used Avail Use% Mounted on
rootfs           16G  1.3G   15G   9% /
devtmpfs         16G     0   16G   0% /dev
tmpfs            16G  8.0K   16G   1% /dev/shm
cgroup_root     8.0M     0  8.0M   0% /sys/fs/cgroup
tmpfs           128M   16M  113M  13% /var/log
/dev/sda1        29G 1016M   28G   4% /boot
overlay          16G  1.3G   15G   9% /lib/modules
overlay          16G  1.3G   15G   9% /lib/firmware
tmpfs           1.0M     0  1.0M   0% /mnt/disks
tmpfs           1.0M     0  1.0M   0% /mnt/remotes
/dev/md1        9.1T  4.6T  4.6T  51% /mnt/disk1
/dev/md2        9.1T  537G  8.6T   6% /mnt/disk2
/dev/nvme0n1p1  932G   68G  863G   8% /mnt/cache
shfs             19T  5.1T   14T  28% /mnt/user0
shfs             19T  5.1T   14T  28% /mnt/user
tmpfs            16G   12M   16G   1% /var/lib/docker/containers

 

Kannst ja berichten, wie es dann bei dir aussieht, ob du noch Writes hast, nachdem du den Eintrag siehst. Ich weiß auch nicht was bei mir da los ist...

Vielleicht wissen mgutt und ich später oder irgendwann mehr

Edited September 9, 20214 yr by MiniKahn

Der eintrag ist jetzt da. Hab viele writes.

Ich kann übrigens die CPU niedrigere CPU auslastung auch nicht bestätigen.

 

 

 

root@Tower:~# find /mnt/cache_raid/appdata -type f -print0 | xargs -0 stat --format '%Y :%y %n' | sort -nr | cut -d: -f2- | head -n30
2021-09-09 12:50:01.754990137 +0200 /mnt/cache_raid/appdata/mariadb/databases/ib_logfile0
2021-09-09 12:50:01.605989534 +0200 /mnt/cache_raid/appdata/mariadb/log/mysql/mariadb-bin.000122
2021-09-09 12:48:55.007720243 +0200 /mnt/cache_raid/appdata/NginxProxyManager/log/proxy_host-1.log
2021-09-09 12:47:04.408275228 +0200 /mnt/cache_raid/appdata/bitwarden/db.sqlite3-shm
2021-09-09 12:46:33.447151153 +0200 /mnt/cache_raid/appdata/bitwarden/db.sqlite3-wal
2021-09-09 12:45:25.450879475 +0200 /mnt/cache_raid/appdata/jdownloader2/cfg/org.jdownloader.settings.AccountSettings.json
2021-09-09 12:45:15.452839626 +0200 /mnt/cache_raid/appdata/jdownloader2/cfg/org.jdownloader.settings.AccountSettings.accounts.ejs
2021-09-09 12:45:05.919801651 +0200 /mnt/cache_raid/appdata/NginxProxyManager/log/proxy_host-5.log
2021-09-09 12:45:05.035798131 +0200 /mnt/cache_raid/appdata/Jellyfin-AMD-Intel-Nvidia/log/log_20210909.log
2021-09-09 12:45:05.034798127 +0200 /mnt/cache_raid/appdata/Jellyfin-AMD-Intel-Nvidia/data/ScheduledTasks/3145e441-d9ba-27fc-391e-7ee15face581.js
2021-09-09 12:45:02.072786334 +0200 /mnt/cache_raid/appdata/Jellyfin-AMD-Intel-Nvidia/data/ScheduledTasks/241d4fcb-19a1-d557-ee62-428e411da609.js
2021-09-09 12:45:01.981785972 +0200 /mnt/cache_raid/appdata/Jellyfin-AMD-Intel-Nvidia/data/ScheduledTasks/a27c5425-9520-b2e5-c509-def68c8f4c45.js
2021-09-09 12:45:01.969785924 +0200 /mnt/cache_raid/appdata/Jellyfin-AMD-Intel-Nvidia/data/ScheduledTasks/1c8ede62-c521-bea0-bf85-1344f5b8ca40.js
2021-09-09 12:45:01.954785864 +0200 /mnt/cache_raid/appdata/Jellyfin-AMD-Intel-Nvidia/data/ScheduledTasks/7d8088c1-0902-f1bf-4072-ded42437bcfb.js
2021-09-09 12:45:01.938785801 +0200 /mnt/cache_raid/appdata/Jellyfin-AMD-Intel-Nvidia/data/ScheduledTasks/2c66a88b-ca43-e565-d7f8-099f825478f1.js
2021-09-09 12:44:19.358616509 +0200 /mnt/cache_raid/appdata/jdownloader2/cfg/org.jdownloader.updatev2.UpdateSettings.json
2021-09-09 12:44:19.357616505 +0200 /mnt/cache_raid/appdata/jdownloader2/cfg/org.jdownloader.extensions.extraction.ExtractionExtension.json
2021-09-09 12:44:10.630581863 +0200 /mnt/cache_raid/appdata/nextcloud/log/php/error.log
2021-09-09 12:44:09.552577586 +0200 /mnt/cache_raid/appdata/mariadb/databases/169cef30bf6e.err
2021-09-09 12:44:09.456577205 +0200 /mnt/cache_raid/appdata/jdownloader2/tmp/7zip/SevenZipJBinding-Qh9xZZgZzGj1/lib7-Zip-JBinding.so
2021-09-09 12:44:09.331576709 +0200 /mnt/cache_raid/appdata/jdownloader2/tmp/myjd.session
2021-09-09 12:44:08.363572868 +0200 /mnt/cache_raid/appdata/jdownloader2/tmp/hosterCache
2021-09-09 12:44:05.978563406 +0200 /mnt/cache_raid/appdata/Jellyfin-AMD-Intel-Nvidia/data/ScheduledTasks/c27fda37-dfb6-e39b-e141-191aaa1c3060.js
2021-09-09 12:44:05.626562009 +0200 /mnt/cache_raid/appdata/jdownloader2/JDownloader.pid
2021-09-09 12:44:05.371560998 +0200 /mnt/cache_raid/appdata/jdownloader2/JD2.port
2021-09-09 12:44:05.367560982 +0200 /mnt/cache_raid/appdata/jdownloader2/JD2.lock
2021-09-09 12:44:02.956551419 +0200 /mnt/cache_raid/appdata/NginxProxyManager/nginx/ip_ranges.conf
2021-09-09 12:44:02.323548908 +0200 /mnt/cache_raid/appdata/NginxProxyManager/logrotate.status
2021-09-09 12:44:02.287548765 +0200 /mnt/cache_raid/appdata/NginxProxyManager/database.sqlite
2021-09-09 12:44:01.993547599 +0200 /mnt/cache_raid/appdata/Jellyfin-AMD-Intel-Nvidia/config/encoding.xml

 

Meiner Ansicht nach macht dieses Gefrickel wenig Sinn, wenn man jeden container anpassen muss weil irgendwelch Daten im appdata ständig geschrieben werden.

Edited September 9, 20214 yr by guybrush2012

3 hours ago, mgutt said:

Ich habe das so verstanden, dass er keinen tag nutzt = latest und die ganze Zeit die Meldung für ein Update bewusst ignoriert, damit er bei der alten Version bleibt. Daher schlug ich ja vor, dass er einen tag setzt, damit er auf die Art die alte Version des Containers erzwingt.

...genau so ist es.

Deshalb müsste ich da ein wenig Forensik betreiben....wann wurde das Image das letzte Mal gezogen und welches tag war da gültig.

Edited September 9, 20214 yr by Ford Prefect

1 hour ago, guybrush2012 said:

Meiner Ansicht nach macht dieses Gefrickel wenig Sinn, wenn man jeden container anpassen muss weil irgendwelch Daten im appdata ständig geschrieben werden.

Nun, das macht schon viel Sinn.... Ansonsten würde jeder healthcheck eines jeden Containers alle 5 oder 30 oder was weiß ich wie viele Sekunden auf deine SSD schreiben. So ist die Abnutzung schon Signifikant geringer. Möchtest du es noch weiter perfektionieren, musst du natürlich jeden Container nochmal anpassen und beispielsweise /var/log oder /log oder wie auch immer in /tmp mounten.

 

Bei dir wurden innerhalb 4 Minuten nur 5 Dateien geschrieben. Das macht einen großen unterschied zu davor.

2021-09-09 12:50:01.754990137 +0200 /mnt/cache_raid/appdata/mariadb/databases/ib_logfile0
2021-09-09 12:50:01.605989534 +0200 /mnt/cache_raid/appdata/mariadb/log/mysql/mariadb-bin.000122
2021-09-09 12:48:55.007720243 +0200 /mnt/cache_raid/appdata/NginxProxyManager/log/proxy_host-1.log
2021-09-09 12:47:04.408275228 +0200 /mnt/cache_raid/appdata/bitwarden/db.sqlite3-shm
2021-09-09 12:46:33.447151153 +0200 /mnt/cache_raid/appdata/bitwarden/db.sqlite3-wal

 

 

Ansonsten hat mir @mgutt sehr geholfen. Wir konnten ein Problem mit einem Plugin identifizieren. Er ist dran und wird sich mit dem Entwickler in Verbindung setzen. Nun läuft alles wie gewollt! Vielen vielen herzlichen Dank!

 

Liebe Grüße

 

Aber woher soll ich wissen was auf den "cache_raid" geschrieben wird?

Fakt ist es werden immer daten geschrieben, aber welche?

Du hast das doch bereits gepostet.

da siehst du die einzelnen Ordner  und Dateien die geschrieben werden..

9 hours ago, guybrush2012 said:

weil irgendwelch Daten im appdata ständig geschrieben werden.

Tatsächlich sehe ich bei deiner Auswertung eher wenige Schreibzugriffe. Schließlich liegen die neuesten 7 Dateien ganze 5 Minuten auseinander. Daraus kann man eher schließen, dass Dateien in /mnt/cache_raid/appdata nicht dein Problem sind. Du solltest eher mal das Dockerverzeichnis /var/lib/docker auswerten (= docker.img oder Dockerpfad auf dem Cache).

On 9/9/2021 at 9:53 PM, mgutt said:

Tatsächlich sehe ich bei deiner Auswertung eher wenige Schreibzugriffe. Schließlich liegen die neuesten 7 Dateien ganze 5 Minuten auseinander. Daraus kann man eher schließen, dass Dateien in /mnt/cache_raid/appdata nicht dein Problem sind. Du solltest eher mal das Dockerverzeichnis /var/lib/docker auswerten (= docker.img oder Dockerpfad auf dem Cache).

 

Das liegt wohl daran das die Zugriffe die homeassistant virtuelle maschine generiert ^^

Ich habe jetzt die Virtuelle Maschine in eine einzelne SSD verschoben.

Dank dir, nutzt sich jetzt meine pool aus 2 Raid1 ssd nicht mehr ab. Danke.

 

Kann ich eigentlich den ordner /mnt/user/system/docker/docker komplett löschen und über apps vorherige apps wird er neu erstellt? Oder ist etwas drin was für Unraid lebensnotwendig ist? 😅

Edited September 13, 20214 yr by guybrush2012

57 minutes ago, guybrush2012 said:

Kann ich eigentlich den ordner /mnt/user/system/docker/docker komplett löschen und über apps vorherige apps wird er neu erstellt? Oder ist etwas drin was für Unraid lebensnotwendig ist? 😅

Nichts wichtiges drin. Siehe auch:

https://forums.unraid.net/topic/99393-häufig-gestellte-fragen/?do=findComment&comment=1010632

Wie kann ich mir bei Unraid die Abnutzung der SSDs (TBW) anzeigen lassen?

3 minutes ago, guybrush2012 said:

Wie kann ich mir bei Unraid die Abnutzung der SSDs (TBW) anzeigen lassen?

Datenträger anklicken und dann bei den SMART Werten schauen.

Ich hätte auch noch einmal eine Frage oder Problem zu dem Umlegen der Logs auf /tmp 🙃

Nachdem ich einen Crash letzte Woche hatte, konnten nach dem Neustart alle Container nicht mehr auf ihre Ordner unter /tmp schreiben. Die Rechte standen auf 755.

 

Habt ihr eine Erklärung hierzu?

 

Ich kann das zwar per Hand ändern, aber wie ich mich kenne habe ich das nach dem nächsten Absturtz in ein paar Monaten wieder vergessen.

10 hours ago, gilladur said:

Nachdem ich einen Crash letzte Woche hatte, konnten nach dem Neustart alle Container nicht mehr auf ihre Ordner unter /tmp schreiben. Die Rechte standen auf 755.

Nach einem Neustart ist der Ordner /tmp leer und Unterordner werden vom Container/Docker neu erstellt. Also egal ob Crash oder nicht, die Ordner müssten dann ja immer nach einem Neustart die falschen Rechte haben?!

11 hours ago, mgutt said:

Nach einem Neustart ist der Ordner /tmp leer und Unterordner werden vom Container/Docker neu erstellt. Also egal ob Crash oder nicht, die Ordner müssten dann ja immer nach einem Neustart die falschen Rechte haben?!

Ich habe jetzt einmal einen Neustart gemacht und die Rechte der neu angelegten Ordner standen wieder auf 0755.

Was für LMS und Nextcloud z.B. zu Problemen führt. Beim setzten von  0777 passt wieder alles.

Wie sieht das bei euch aus und was wäre zu erwarten?

 

Mir war das über die ganze Zeit nicht aufgefallen, da ich den Server nach dem Einrichten der TMP-Geschichte nie neu gestartet hatte ;-)

Dh wenn man das beim Container einstellt wird es 777 und wenn man den Server neu startet, dann 755? Dann müsste das auch passieren, wenn man den Container stoppt, den Unterordner löscht und ihn wieder startet. Das wäre dann quasi ein Bug in Docker oder unRAID. Also wer auch immer den Ordner erstellt.

19 minutes ago, mgutt said:

Dh wenn man das beim Container einstellt wird es 777 und wenn man den Server neu startet, dann 755? Dann müsste das auch passieren, wenn man den Container stoppt, den Unterordner löscht und ihn wieder startet. Das wäre dann quasi ein Bug in Docker oder unRAID. Also wer auch immer den Ordner erstellt.

Ich habe das mal getestet.
Zumindest bei mir ist es so, dass die Ordner nur initial mit den richtigen Rechten gesetzt werden, wenn also man die Einstellungen ändert und dies dann Anwendet. In dem Fall passt dann alles.

Und du nimmst richtig an, wenn ich die Ordner lösche und den Container neu starte, dann werden die Rechte nicht korrekt gesetzt.

 

Keine Ahnung, ob das nur bei mir so ist?

@ich777

Weißt du ob unRAID selbst die Ordner erstellt, die man im Template als Path verlinkt (also wenn der Zielordner noch nicht existiert)? Oder passiert das durch den Docker Service?

9 minutes ago, mgutt said:

Docker Service?

Durch den Docker Service.