Posts by florian-muc

ich sehe gerade in der Kompatibilitätsliste, dass die 10TB WD100EFGX dort enthalten ist.

Das ist quasi mein Modell (WD101EFBX) nur mit 512 MB Cache statt 256MB. Da kann man die Kirche auch mal im Dorf stehen lassen.

Die Liste hat mich damals nicht interessiert.
Ich habe zu dem Zeitpunkt nur Testberichte zu diesen Festplattenmodellen angeschaut.

Ich nutze auch 32GB Crucial RAM problemlos, obwohl die DXP2800 offiziell nur 16GB unterstützt.

Ich nutze in meiner DXP2800 vollkommen problemlos zwei WD WD101EFBX 10TB (WD Red Plus-NAS-Festplatte 256MB Cache).

10 TB WD Red Plus-NAS-Festplatte 3,5 Zoll | Western Digital

Die WD Red Plus NAS-Festplatte wurde für kleine und mittelständische Unternehmen entwickelt und bietet Ihnen Leistung, Flexibilität, Vielseitigkeit und…

www.westerndigital.com

Hab das Update aus 4000km Entfernung gemacht. Wie bei dem letzten Update auch dank des Check & Fix Permissions Scriptes und Monitor Services keinerlei SSH Probleme (non-root). Ohne hätte ich wohl manuell eingreifen müssen.

UGOS_scripts/ssh_public_key/README.md at main · ln-12/UGOS_scripts

Helper scripts and services for UGOS (UGREEN NASync OS) - ln-12/UGOS_scripts

github.com

Habe meinen auch storniert bei dem großen Fluss und drei Tage später ist der USV nun mit UPS angekommen. Bin gespannt.

Quote from Marlachisch

Es geht auch einfach, indem man ein Ticket eröffnet und eine xxx.bin Datei vom Support erhält. Damit gehts dann ganz normal weiter in der Systemsteuerung USV -> Manuell aktualisieren.

Alternativ auch als Download Firmware Download US3000

Danke, das Update der Firmware war durch deinen Link sehr einfach und hat einwandfrei funktioniert.

*kw* danke!

Naja, am Ende ist es auch nur die kleine Korrektur eines Buchstabens in der Docker Compose von Duplicati nach einem Fimware Update. Dauert eine Minute, also auch kein Drama. Nutze aber auch nur ein USB Laufwerk.

Hatte auch deinen Marker-File Tipp beherzigt.

Bevor es zu Off-Topic wird….

Bin jedenfalls sehr zufrieden mit der Update Politik von Ugreen.

Ich habe nur noch nicht storniert, weil ich einen zehn Euro Ugreen-Gutschein bei Amazon hatte. Ich hab aber auch keine Lust jetzt noch bis Oktober zu warten, wegen den zehn Euro. Wenn Ugreen flott versendet, storniere ich auch.

Die einzige Kleinigkeit, die ich gerade bemerkt habe, ist, dass durch den Neustart des NAS meine externe SSD, die ich für ein Backup in Duplicati nutze, einen neuen Mount Point bekommen hat.

Kann man das NAS nach einem Neustart irgendwie dazu „bewegen“, immer den gleichen Laufwerksbuchstaben zuweisen, also z.b sdc1 statt sdd1?

Hab das Update auch problemlos durchgeführt. Diesmal hatte ich keine SSH Permission Probleme nach dem Update, so dass die Key-Passphrase nicht mehr ging.

Habe auch seit dem letzten Update daher das SSH permission / Monitor Script laufen, aber laut Logs musste es bei diesem Update gar nichts korrigieren.

Hi Protogonos,

in meinem gesamten Cloudflare-Setup nutze ich zwei Cloudflare Tunnel: einen für meinen Cloud Server mit allen Containern und einen für mein NAS mit allen Containen.

Die Implementierung auf meinem NAS basiert auf einem einzelnen Cloudflared-Container (wie du schon richtig bemerkt hast ), der als zentraler Reverse-Proxy für alle extern erreichbaren Dienste fungiert. Die Weiterleitung des Traffics an die korrekten internen Container wird über Hostname-basierte Ingress-Regeln (in der zentralen Konfigurationsdatei config.yml) gesteuert.

Ich komme in meinem Setup wunderbar auch mit dem Ressourcenverbrauch klar und habe auch keine Probleme mit den Containern.

Jeder Dienst ist über eine eigene Subdomain erreichbar. Dazu habe ich eine Domain bei Cloudflare konfiguriert und dort in den DNS Settings entsprechend die Sub-Domains mit dem der entsprechenden Tunnel ID als Target konfiguriert und dem internen Dienstnamen der jeweiligen Container.

Der Tunnel inspiziert den angefragten Hostnamen und leitet den Traffic gemäß der definierten Regel an den entsprechenden internen Service weiter. Zusätzlich habe ich dann noch pro Dienst in den Zero Trust Settings "Applications" mit meiner Access Policy angelegt.

Tailscale wird von mir dann nicht wirklich als Alternative, sondern als reine Ergänzung für spezifische Anwendungsfälle eingesetzt, die z.B. rein gar nicht für den öffentlichen Web-Zugriff vorgesehen sind (z.B. die Management GUI von syncthing - alle anderen Container laufen bei mir aber aktuell via cloudflared), selbst wenn diese hinter Cloudflare gesichert wäre. Oder halt auch Zugriff auf das NAS via SSH im lokalen Netzwerk.

Hier ansonsten mal beispielhaft ein paar Ingress-Regeln einer möglichen Cloudflared config.yml, wie ich sie im Prinzip nutze:

# /pfad/zur/config.yml auf dem NAS

# --- Globale Tunnel-Konfiguration ---
# Definiert den Namen des Tunnels, der ausgeführt werden soll.
tunnel: mein-nas-tunnel

# Pfad zur Credentials-Datei mit der eindeutigen Tunnel-ID.
credentials-file: /home/nonroot/.cloudflared/abc123efg3456.json

# --- Ingress-Regeln (Routing-Tabelle) ---
ingress:
  # Regel 1: Leitet Traffic für 'docker.meine-domain.de'
  - hostname: docker.meine-domain.de
    # an den internen Dienst 'portainer-nas' auf Port 9000.
    service: http://portainer-nas:9000

  # Regel 2: Leitet Traffic für 'paperless.meine-domain.de'
  - hostname: paperless.meine-domain.de
    # an den internen Dienst 'paperless-ngx-webserver-nas' auf Port 8000.
    service: http://paperless-ngx-webserver-nas:8000

  # Regel 3: Leitet Traffic für 'ha.meine-domain.de'
  - hostname: ha.meine-domain.de
    # an eine feste IP, da der Dienst im Host-Netzwerk läuft.
    service: http://192.168.178.2:8123

  # ... und so weiter für diverse weitere Dienste.

  # Catch-All-Regel: Alles andere, was nicht definiert ist, wird abgewiesen.
  - service: http_status:404

Insgesamt bin ich bisher relativ zufrieden mit meinem Setup ohne Portfreigaben

Hi,

naja, ich habe da ein paar individuelle Scripte im Einsatz. Hier aber mal Beispiele für einfache Shell Scripte.

Paperless export

#!/bin/sh

docker exec paperless-ngx-webserver-nas document_exporter /usr/src/paperless/export --delete

Docker prune

#!/bin/sh

docker system prune -af

Und hier mal ein Beispiel, wie ich ein vorher als Volume im Docker Container gemountetes Script aufrufe:

#!/bin/sh

cd /usr/local/bin/ && ./check_permissions.sh

Und so sieht der Mount des Scriptes in der Docker Compose als Volume aus:

volumes:
  - /volume1/beispiel-verzeichnis/check_permissions.sh:/usr/local/bin/check_permissions.sh:ro

Super Willi, das freut mich!

Hier nochmal mein Docker Compose-Beispiel, falls es noch mehr Interessierte gibt, die Cronicle testen wollen

Quote from florian-muc

Das Setup von Cronicle hat mich ein paar Nerven gekostet. Musste im Container noch bash installieren und den docker client und dann auch die genutzen Scripte als Volumes mounten. Auch das Setup der Mail Options war etwas kompliziert.

@GreenEbu : Anbei meine Docker-Compose (mit Beispielpfaden), falls es hilft...

(Der entrypoint ist ein wichtiger Fix, da das Image in meinem Fall sonst Probleme mit Berechtigungen hatte und bash für komplexere Skripte fehlt. Die Installation vom Docker-CLI im entrypoint und den Zugriff auf Docker kann man natürlich weglassen, wenn man es für Cronicle nicht braucht)

Code

# Pfad: /dein/docker/verzeichnis/stacks/cronicle/docker-compose.yml
# Beispiel-Konfiguration für Cronicle Job-Scheduler

services:
 cronicle:
   # Community-gepflegtes Image, das als non-root laufen kann
   image: soulteary/cronicle:0.9.80
   container_name: cronicle
   restart: unless-stopped

   # --- WICHTIGER FIX ---
   # Passt den Container beim Start an:
   # 1. Installiert 'bash' und den 'docker'-Client für Skripte.
   # 2. Korrigiert Ausführungsrechte für das interne Shell-Plugin.
   entrypoint: |
     /bin/sh -c "apk add --no-cache bash docker && \
                 chmod 755 /opt/cronicle/bin/shell-plugin.js && \
                 exec /opt/cronicle/bin/docker-entrypoint.js"

   environment:
     - TZ=Europe/Berlin
     # --- SECRETS (als Variablen z.B. aus einer .env-Datei laden oder in den ENV Block in Dockge eintragen) ---
     - CRONICLE_secret_key=${C_SECRET_KEY}

     # --- Web & SMTP Konfiguration (Beispiele) ---
     - CRONICLE_base_app_url=https://cronicle.deine-domain.de
     - CRONICLE_email_from=Dein NAS <${C_SMTP_USER}>
     - CRONICLE_smtp_hostname=${C_SMTP_HOST}
     - CRONICLE_smtp_port=${C_SMTP_PORT}
     - CRONICLE_mail_options__secure=true
     - CRONICLE_mail_options__auth__user=${C_SMTP_USER}
     - CRONICLE_mail_options__auth__pass=${C_SMTP_PASS}
     
     # --- WICHTIGER FIX ---
     # Leitet das Queue-Verzeichnis um, damit der non-root User Schreibrechte hat.
     - CRONICLE_queue_dir=/opt/cronicle/data/queue

   volumes:
     # --- PERSISTENTE DATEN ---
     # Hier speichert Cronicle seine Konfiguration, Jobs und Plugins.
     - /dein/docker/verzeichnis/data/cronicle/data:/opt/cronicle/data
     - /dein/docker/verzeichnis/data/cronicle/logs:/opt/cronicle/logs
     - /dein/docker/verzeichnis/data/cronicle/plugins:/opt/cronicle/plugins

     # --- EIGENE SKRIPTE (Beispiele) ---
     # Hier bindest du deine eigenen Skripte ein, die von Cronicle ausgeführt werden sollen.
     # Der ':ro' Zusatz (read-only) ist eine gute Sicherheitspraxis.
     - /dein/skript/verzeichnis/docker_backup.sh:/usr/local/bin/docker_backup.sh:ro
     - /dein/skript/verzeichnis/check_permissions.sh:/usr/local/bin/check_permissions.sh:ro
     
     # --- ZUGRIFF AUF DOCKER ---
     # Notwendig, damit Cronicle Docker-Befehle ausführen kann.
     - /var/run/docker.sock:/var/run/docker.sock

   networks:
     # Dein zentrales Docker-Netzwerk
     - dein_docker_netzwerk

   deploy:
     resources:
       limits:
         memory: 512M

   healthcheck:
     test: ["CMD", "curl", "-sf", "http://localhost:3012/api/app/status"]
     interval: 30s
     retries: 3

networks:
 dein_docker_netzwerk:
   external: true

Display More

Quote from Kalle345

Protogonos Das klingt gut. soweit ich weiß komme ich mit meinem DXP2800 aber nur auf maximal 16GB RAM. Keine Ahnung ob das noch nennenswert ist wenn ich mir deine knapp 63GB RAM anschaue.

Aktuell sitz ich noch auf 8GB. Werd aber bald wie möglich aufrüsten.

Ich komme dann gern auf deinen Vorschlag zurück. Ich mache mir nur Sorgen dass die Konstellation für mich zu kompliziert wird wenn ich mal auf Schwierigkeiten reagieren muss.

eineb Das Jellyfin TUT habe ich schon gesehen. Hab gedacht/gehofft dass die hauseigene Alternative "noch" einfacher wäre.

Ich glaube ich hab auch schon bei der Ordnerstruktur Fehler gemacht. Aber gut. Werd dann Jellyfin mit der Anleitung aus dem Forum neuinstallieren. Vielleicht läuft es dann ohne zu wissen was mein Fehler war.

Wie wäre denn die Reihenfolge wie ich vorgehen müsste wenn ich deine Hinweise einbeziehe? Muss mich vorab ein bissl einlesen

> Docker kann erstmal so auf SSD bleiben, nur Jellyfin deiinstallieren

> Dann informieren über MacVlan und Portainer?

Jetzt werd ich erstmal zur Arbeit. Schaue in den Pausen hier nochmal rein.

Und dann nach Arbeit ...Attacke

Display More

Ich hab in meiner DXP2800 32GB Crucial RAM verbaut. Läuft problemlos und würde ich auch empfehlen. Wird auch gut ausgenutzt für das Caching.

Ich habe mir beim großen Fluss den Riegel hier gekauft: Crucial RAM CT32G48C40S5 32GB DDR5 4800MHz CL40

Quote from GreenEbu

florian-muc Ja vielen Dank für Deinen Support.

Vielleicht sollte ich meine ursprünglichen Zeilen mit dem Hinweis "...versuchen werde zu Testzwecken ..." ergänzen.

Denn, wenn ich Deine Zeilen so lese, scheint das nicht "quick & dirty" zu gehen. Als einer vom Synology DSM 'verdorbener' (noch nicht vollständiger) Herstellerwechsler könnte das ein grössere Herausforderung werden

Ich denke bzw. hoffe, dass diese Compose Vorlage das Setup von Cronicle via Docker mit dem Image eigentlich nun relativ unkompliziert macht. Also viel Spaß beim ausprobieren!

Quote from buchling

Cronicle sieht wirklich sehr interessant aus, das schau ich mir auch mal an. Vielen Dank für deine Docker-Compose!

Paperless-AI kannte ich auch noch nicht, kommt auch auf meine Experimentierliste.

Paperless-AI finde ich top! Allerdings kann ich nur den Tip mitgeben, dass man nur Dokumente von Paperless-AI bearbeiten lässt, die man mit einem bestimmten Tag wie z.B. "ai" in Paperless-ngx markiert. Und man sollte zur Sicherheit natürlich vorher auch einen Export der Dokumente mit dem Status quo vor der Installation von Paperless-AI machen.
Dann hat man das unter Kontrolle.
Das einzige Geheimnis ist, dass man sich etwas Mühe mit dem Prompt in den Einstellungen geben und da am Anfang etwas rumprobieren muss.

Super. Danke euch!

Stimmt, ist mir gar nicht aufgefallen. Hab versucht da im Taskmanager Prozessen und im Log Infos zu finden, aber scheinbar kann man den Stand da ja sehen.

Als es abgeschlossen worden ist, war da erstmal "Ruhe" bei dir? Oder beansprucht die KI-Funktion das NAS dauernd, auch wenn man keine neuen Fotos hinzufügt? Mir wäre der Ruhezustand für meine HDDs schon wichtig

Das Setup von Cronicle hat mich ein paar Nerven gekostet. Musste im Container noch bash installieren und den docker client und dann auch die genutzen Scripte als Volumes mounten. Auch das Setup der Mail Options war etwas kompliziert.

@GreenEbu : Anbei meine Docker-Compose (mit Beispielpfaden), falls es hilft...

(Der entrypoint ist ein wichtiger Fix, da das Image in meinem Fall sonst Probleme mit Berechtigungen hatte und bash für komplexere Skripte fehlt. Die Installation vom Docker-CLI im entrypoint und den Zugriff auf Docker kann man natürlich weglassen, wenn man es für Cronicle nicht braucht)

# Pfad: /dein/docker/verzeichnis/stacks/cronicle/docker-compose.yml
# Beispiel-Konfiguration für Cronicle Job-Scheduler

services:
 cronicle:
   # Community-gepflegtes Image, das als non-root laufen kann
   image: soulteary/cronicle:0.9.80
   container_name: cronicle
   restart: unless-stopped

   # --- WICHTIGER FIX ---
   # Passt den Container beim Start an:
   # 1. Installiert 'bash' und den 'docker'-Client für Skripte.
   # 2. Korrigiert Ausführungsrechte für das interne Shell-Plugin.
   entrypoint: |
     /bin/sh -c "apk add --no-cache bash docker && \
                 chmod 755 /opt/cronicle/bin/shell-plugin.js && \
                 exec /opt/cronicle/bin/docker-entrypoint.js"

   environment:
     - TZ=Europe/Berlin
     # --- SECRETS (als Variablen z.B. aus einer .env-Datei laden oder in den ENV Block in Dockge eintragen) ---
     - CRONICLE_secret_key=${C_SECRET_KEY}

     # --- Web & SMTP Konfiguration (Beispiele) ---
     - CRONICLE_base_app_url=https://cronicle.deine-domain.de
     - CRONICLE_email_from=Dein NAS <${C_SMTP_USER}>
     - CRONICLE_smtp_hostname=${C_SMTP_HOST}
     - CRONICLE_smtp_port=${C_SMTP_PORT}
     - CRONICLE_mail_options__secure=true
     - CRONICLE_mail_options__auth__user=${C_SMTP_USER}
     - CRONICLE_mail_options__auth__pass=${C_SMTP_PASS}
     
     # --- WICHTIGER FIX ---
     # Leitet das Queue-Verzeichnis um, damit der non-root User Schreibrechte hat.
     - CRONICLE_queue_dir=/opt/cronicle/data/queue

   volumes:
     # --- PERSISTENTE DATEN ---
     # Hier speichert Cronicle seine Konfiguration, Jobs und Plugins.
     - /dein/docker/verzeichnis/data/cronicle/data:/opt/cronicle/data
     - /dein/docker/verzeichnis/data/cronicle/logs:/opt/cronicle/logs
     - /dein/docker/verzeichnis/data/cronicle/plugins:/opt/cronicle/plugins

     # --- EIGENE SKRIPTE (Beispiele) ---
     # Hier bindest du deine eigenen Skripte ein, die von Cronicle ausgeführt werden sollen.
     # Der ':ro' Zusatz (read-only) ist eine gute Sicherheitspraxis.
     - /dein/skript/verzeichnis/docker_backup.sh:/usr/local/bin/docker_backup.sh:ro
     - /dein/skript/verzeichnis/check_permissions.sh:/usr/local/bin/check_permissions.sh:ro
     
     # --- ZUGRIFF AUF DOCKER ---
     # Notwendig, damit Cronicle Docker-Befehle ausführen kann.
     - /var/run/docker.sock:/var/run/docker.sock

   networks:
     # Dein zentrales Docker-Netzwerk
     - dein_docker_netzwerk

   deploy:
     resources:
       limits:
         memory: 512M

   healthcheck:
     test: ["CMD", "curl", "-sf", "http://localhost:3012/api/app/status"]
     interval: 30s
     retries: 3

networks:
 dein_docker_netzwerk:
   external: true

Hier ein kleines Update

Mittlerweile habe ich eigentlich alles installiert, was ich so wollte und auf dem Schirm hatte. Natürlich bin ich für Tipps mit spannenden Docker Containern jederzeit offen ...

Meine neueren Container:

Ich habe mittlerweile für fast alle Container "healthchecks" in den docker-compose Dateien integriert, daher ist Autoheal natürlich sehr nützlich und unkompliziert.



Ansonsten habe ich zuletzt nach einer Lösung gesucht, wie ich in einer GUI regelmäßige Cronjobs komfortabel einrichten und ausführen kann und benachrichtigt werde. In meiner Recherche bin ich auf Cronicle aufmerksam geworden. Es steht ein von der Community gepflegter Docker Container hier zur Verfügung, den ich nutze.

Hier mal ein kurzer Eindruck meines initialen Cronicle Job-Setups:

Hallo zusammen,

ich habe meine gesamten iCloud Fotos & Videos (knapp 43.000) jetzt mal testweise auf mein NAS geschoben. Gleichzeitig habe ich diverse KI Funktionen in den KI-Einstellungen in der Fotos App aktiviert (nur nicht die Erkennung in Videos). Mein NAS rödelt nun seit zwei Tagen und die CPU Temperatur ist seitdem ca. bei 80 Grad... Die Erstellung der Miniaturansichten, Erkennung der Orte und Personmen scheint durch zu sein.


Zwei Fragen an die Profis:

- wie lange dauert das eurer Erfahrung nach, bis mal alles "abgeschlossen" ist?

- wenn ich jetzt keine neuen Fotos hinzufüge, werden diese KI-Funktionen trotzdem dauernd ausgeführt? Oder habe ich irgendwann noch die Chance, dass mein Volume 2 (HDDs), wo die Fotos liegen, mal wieder in den Ruhezustand geht?

DANKE!!

Hi, ich habe Squoosh bisher nicht genutzt, daher kann ich das nicht vergleichen. Mazanoke ist hübsch und simpel. Das trifft wohl auch auf Squoosh zu, wie ich gerade sehe

Hast du ggf. den Link zum Docker Container der Squoosh GUI zur Hand? Ich habe auf die schnelle nur die CLI Version gefunden.