Patty92

Hey, ich habe das Problem das ich an der Docker Config etwas anpassen wollte. Nachdem ich den Dienst beendet habe, habe ich keine Möglichkeit mehr Sachen anzupassen oder auch den Dienst überhaupt wieder zu starten.

That's right. No problem at all, I just noticed it and thought here might be the best place to report a "possible error". Greetings Patty

I first terminated the container and then the service. Yes, I did. It was a coincidence that I had this constellation. Again, a little more detail on the sequence: Stop LXC container Wechsel zum Dashboard - Container war beendet Switch to LXC settings - Enable LXC - no Click Update Switch to dashboard LXC containers are visible and active again I would argue that if I disable the service, yes the containers should not start again. Maybe even remove the display from the dashboard when the service is disabled. I hope this is understandable so far.

Hey, here's what I noticed: Version: 6.12.0-rc2 - Stop LXC container - Stop LXC service - Switch to dashboard - LXC containers are visible and active again

Hey, I installed a fresh 6.12.0-rc2 on a test system to test a few things. Here I noticed when I use the script "RAM disk for Docker json/log files v1.3" it comes to the error: Mar 22 05:48:01 TOWER crond[1018]: exit status 255 from user root /usr/local/emhttp/plugins/dynamix/scripts/monitor &> /dev/null Mar 22 05:49:01 TOWER crond[1018]: exit status 255 from user root /usr/local/emhttp/plugins/dynamix/scripts/monitor &> /dev/null Mar 22 05:50:01 TOWER crond[1018]: exit status 255 from user root /usr/local/emhttp/plugins/dynamix/scripts/monitor &> /dev/null Mar 22 05:51:01 TOWER crond[1018]: exit status 255 from user root /usr/local/emhttp/plugins/dynamix/scripts/monitor &> /dev/null This error occurs every full minute. After I removed the script and restarted the system, the error no longer occurs. Greetings Patty

Das ist so korrekt. Ich habe mal eine "frische" install gemacht: Version: 6.12.0-rc2

Nutzt du den Container von lscr.io/linuxserver ? Da kam später nochmal ein Update raus in dem unter "/config/nginx/site-confs/" die default.conf aktualisiert wurde. In den Container logs siehst du dann: old date │ new date │ path │ 2022-08-20 │ 2023-03-21 │ /config/nginx/site-confs/default.conf Sollttest du die "default.conf" nicht angepasst haben, kannst du: - Container beenden - default.conf löschen - Container starten Im Nachgang wird auf Basis der "default.conf.sample" die Datei neu angelegt.

Soooo.. Stück für Stück probiert, abgewartet, geprüft: 04.03.2023 Deleted files File sharing Password policy Right click 05.03.2023 - 04:40 Uhr - Kein WakeUp 05.03.2023 Privacy Related Resources Support 06.03.2023 - 04:40 Uhr - Kein WakeUp 06.03.2023 Log Reader Monitoring Nextcloud announcements Notifications Update notification 07.03.2023 - 04:40 Uhr - Kein WakeUp 08.03.2023 Brute-force settings 09.03.2023 - 04:40 Uhr - WakeUp

Könnte es damit zusammen hängen? Es wird nicht empfohlen das Array mit USB-Platten zu nutzen.

Sieh dir mal die Posts eine Seite vorher an. Seite 4 (Posts 30. Juli - 31. Juli) Problem ist der standardmäßige Zwang einer Internetverbindung. Kann aber umgangen werden (Post 31. Juli) Gruß

This image is deprecated. We will not offer support for this image and it will not be updated. The last working tag is: v2.0.1-ls60 We recommend the official image instead: https://hub.docker.com/r/papermerge/papermerge Zumindest wenn man „neu“ anfängt wäre das die bessere Optionen. War der Container schon aktiv im Einsatz ist die Frage wie bei den anderen, wie bekommt man die Daten auf den offiziellen Container überführt. Wenn ich das richtig verfolgt habe, scheint es keinen Ex-/Import zu geben.

Da haben wir den Übeltäter eingegrenzt. Ich habe gestern alle aktivierten Apps deaktiviert und heute kein SpinUp. Nun heißt es Stück für Stück probieren. Sobald ich mehr weiß, reiche ich das ganze noch nach. Vielen Dank nochmal @hawihoney

das wird es wohl sein 😃 Kein Problem. Ich schau mal ob sich bei der Deaktivierung der Apps was tut. Vielen Dank für die Hilfe. 🙃

Das Problem ist ja aufgetreten. Ich habe den CronJob deaktiviert, sodass das Script nicht ausgeführt wird. Resultat war, das heute früh die Platte 4.40 Uhr anging.

Wie gesagt, habe ich gestern den CronJob des Scripts deaktiviert. Mar 3 04:40:02 HOMESERVER emhttpd: read SMART /dev/sdc Mar 3 05:40:13 HOMESERVER emhttpd: spinning down /dev/sdc Leider nichts zu sehen. root@HOMESERVER:~# find /mnt/disk1/ -newermt "2023-03-03 04:35:00" ! -newermt "2023-03-02 04:45:00" root@HOMESERVER:~# find /mnt/disk1/ -newerat "2023-03-03 04:35:00" ! -newerat "2023-03-02 04:45:00" root@HOMESERVER:~# root@HOMESERVER:~# root@HOMESERVER:~# find /mnt/disk1/ -newermt "2023-03-03 04:30:00" ! -newermt "2023-03-02 05:50:00" root@HOMESERVER:~# find /mnt/disk1/ -newerat "2023-03-03 04:30:00" ! -newerat "2023-03-02 05:50:00" root@HOMESERVER:~# Ich werde das jetzt einfach mal probieren, alle zu deaktivieren. In meinem Fall sind das folgende: Brute-force settings Deleted files File sharing Log Reader Monitoring Nextcloud announcements Notifications Password policy Privacy Related Resources Right click Support Update notification

root@HOMESERVER:~# ls -la /mnt/disk1/ total 4 drwxrwxrwx 8 nobody users 128 Dec 20 13:59 ./ drwxr-xr-x 9 root root 180 Feb 26 17:14 ../ drwxrwxrwx 9 nobody users 138 Feb 12 17:20 Backup/ drwxrwxrwx 27 nobody users 4096 Dec 31 13:36 Bilder/ drwxrwxrwx 8 nobody users 172 Oct 28 19:38 Filme\ und\ Serien/ drwxrwxrwx 6 nobody users 118 Jan 7 01:56 Software/ drwxrwxrwx 5 nobody users 70 Feb 21 13:49 Temp/ drwxrwxrwx 7 nobody users 123 Jul 12 2022 Videos/ #!/bin/bash # CronJob 39 4 * * * docker stop nextcloud sleep 180 docker start nextcloud

Moin Moin, hier die gleiche Konstellation wie bei Nextcloud: - /mnt/cache/appdata/mariadb-official/data - /mnt/cache/appdata/mariadb-official/config Wie gestern erwähnt, habe ich heute nochmal den Test mit dem UserScript gemacht. Auch heute (02.03) kein aufwachen der disk1. Ich werde das Script heute "deaktivieren" und schauen ob die Platte morgen wieder angeht. Sollte dies der Fall sein, werde ich mal in der nextcloud die aktivieren Apps deaktivieren. Danke für dein Feedback, ein Interessanter einwand, mal schauen wo die Ergebnisse hinführen. 😃

Sehr gut 👍 Du kannst ja die Lösung noch mit "Mark as Solution" markieren. Dann sehen die Leute in der Übersicht, dass das Problem gelöst ist und im Beitrag kann man gleich zur Lösung "springen". Kein Problem. 🙃 Grüße Patty

Nachdem du die Freigabe erstellt hast kommen nach Übernehmen dieser Einstellungen im unteren Bereich die "SMB Security Settings". Steht dort "Export" auf "No? Bzw. kommst du über UNC-Pfad drauf? \\Server\Freigabename Beispiel: \\Tower\Musik

Du meinst eine "ganz normale" Freigabe? Dann am besten mal hier gucken:

nächstes Update: Ich gehe mal davon aus, das ich mit Befehl "lsof" zu den entsprechenden Zeitpunkt (hier 4:40 Uhr) arbeiten müsste. In meinem Fall "lsof /mnt/disk1/". Da ich jetzt noch nicht die Lust hatte um diese Zeit aufzustehen ^^ .. habe ich erstmal überlegt was ich geändert habe. Dann fiel mir ein, das ich den nextcloud Container (von linuxserver) in letzter Zeit "durchlaufen" lasse. Sonst habe ich das ganze nur bei Bedarf an geschalten. Nun habe ich am 06.02 den Container beendet. 07.02 - 04.40 Uhr - kein WakeUp der disk1 07.02 habe ich UserScript erstellt - Beende den Container 04.39 Uhr, starte den Container 4:42. 08.02 - 04.40 Uhr - kein WakeUp der disk1 Ob es 100% daran liegt, kann ich noch nicht sagen, die zufälle bestätigen es aber derzeit. Was ich auch nicht verstehe, der Container hat eigtl. keinen Bezug zu der disk1. Einzige Konfiguration des Container: /mnt/cache/appdata/nextcloud/data /mnt/cache/appdata/nextcloud/config Ich werde jetzt das ganze noch einen Tag so lassen und schauen das wieder "nichts passiert" und danach den CronJob mal deaktivieren um zu sehen ob die Platte dann am darauf folgenden Tag wieder aufwacht.

Genau so sieht es aus, die Parity Platte bleibt unberührt. 👍 so wird es gemacht. 🙂

Kleine Zwischenbilanz: # System Protokoll Feb 24 01:06:01 HOMESERVER emhttpd: read SMART /dev/sdc Feb 24 04:19:21 HOMESERVER emhttpd: spinning down /dev/sdc Feb 24 04:40:01 HOMESERVER emhttpd: read SMART /dev/sdc Feb 24 05:40:13 HOMESERVER emhttpd: spinning down /dev/sdc # File Activity # die letzten 7 Einträge Feb 24 01:06:01 OPEN => /mnt/disk1/. . . Feb 24 01:06:36 OPEN => /mnt/disk1/. . . Feb 24 01:06:54 OPEN => /mnt/disk1/. . . Feb 24 01:07:21 OPEN => /mnt/disk1/. . . Feb 24 01:21:29 OPEN => /mnt/disk1/. . . Feb 24 02:02:58 OPEN => /mnt/disk1/. . . Feb 24 02:44:27 OPEN => /mnt/disk1/. . . WIe man sieht, hat "File Activity" leider nichts protokolliert. Also heißt es, anderweitig auf Suche gehen.

- Plex Server ist bei mir im Einsatz, die Vermutung habe ich auch, das dieser damit zutun hat. - Die geplanten Aufgaben im Plex habe ich schon alle deaktiviert sodass der eigtl. nichts machen dürfte. - Werde ich mir mal genauer ansehen, vielen Dank dafür - Habe ich eigtl. - anscheinend zu "dusslig" angestellt I'm sorry - Falsch ausgedrückt, ja. - es handelt sich um disk1 (derzeit die einzige) - Diese Sachen können alle zu dieser Uhrzeit ausgeschlossen werden. Ich danke erstmal, ich werde mal mit "lsof" und dem erwähnten Plguin auf Suche gehen.

Hey, wie man oben dem Titel schon entnehmen kann, wacht meine Platte immer zur gleichen Zeit auf. Feb 13 04:40:03 HOMESERVER emhttpd: read SMART /dev/sdc Feb 13 05:40:23 HOMESERVER emhttpd: spinning down /dev/sdc # # # wieso hier fast eine Woche Ruhe ist.. gute Frage Feb 19 04:40:01 HOMESERVER emhttpd: read SMART /dev/sdc Feb 19 05:40:23 HOMESERVER emhttpd: spinning down /dev/sdc Feb 20 04:40:02 HOMESERVER emhttpd: read SMART /dev/sdc Feb 20 05:40:13 HOMESERVER emhttpd: spinning down /dev/sdc Feb 21 04:40:01 HOMESERVER emhttpd: read SMART /dev/sdc Feb 21 05:40:23 HOMESERVER emhttpd: spinning down /dev/sdc Feb 22 04:40:02 HOMESERVER emhttpd: read SMART /dev/sdc Feb 22 05:40:23 HOMESERVER emhttpd: spinning down /dev/sdc Feb 23 01:08:45 HOMESERVER emhttpd: read SMART /dev/sdc Feb 23 05:40:03 HOMESERVER emhttpd: spinning down /dev/sdc # # # Hier wurde auf die Mediathek zugegriffen, deshalb das "frühe" aufwachen Mich würde jetzt interessieren, ob und wie ich das ganze prüfen kann, wieso diese Platte aufwacht. Logs oder ähnliches wenn ja welche / wo? Angenehmen Start in den Donnerstag. Grüße Patty