Posts by ACiAtuRA

    • Erkennung einer bereitgestellten Aktualisierung wird korrekt angezeigt
    • Auslösen einer Aktualisierung:
      • a) fehlerhaft, wird nicht durchgeführt
      • b) wird durchgeführt, aber hinterlässt fehlerhafte Image-Duplikate (bspw. jdownloader, glutun, homeassistent)

    c) Container startet nicht mehr (scheinbar zufällig, mal trifft es den einen, dann einen anderen Container)

    Ich habs längst aufgegeben mit der Aktualisierungsfunktion. Musste mehrmals eingreifen:

    docker-compose up --force-recreate --build -d

    Die fehlerhaften Image-Duplikate sind nichts neues, einfach löschen, fertig.

    Tommes
    August 3, 2025 at 6:09 PM

    auch wenn Sync & Backup auf Duplicati beruhen soll.

    Sync & Backup beruht auf den beiden Open Source Projekten restic und syncthing

    Code
    /volume1/@appstore/com.ugreen.syncbackup $ bin/restic version
    restic 0.17.1 (ee678eeaa-dirty) compiled with go1.23.1 on linux/amd64
    
    /volume1/@appstore/com.ugreen.syncbackup $ bin/syncspace
    [start] 2025/08/03 14:22:35 INFO: syncthing v1.26.1 "Gold Grasshopper" ...

    Fun fact: restic verschlüsselt Backups. Sync & Backup benutzt einen hardcoded Schlüssel (RESTIC_PASSWORD=ugreen).

    Tommes, good catch!

    Korrekt ist folgender Einzeiler sudo chmod 750 $(find /home -mindepth 1 -maxdepth 1)

    Code
    # Function to set permissions
    set_permissions() {
        echo "Checking permissions..."
    
        sudo chmod 750 $(find /home -mindepth 1 -maxdepth 1) # brute-forcing for all users

    Seit der UGOS Pro Version 1.5 oder 1.6 nicht mehr benötigt, da die Inhalte der Benutzerordner an sich durch UGOS Pro nicht mehr angefasst werden. Einzig die Benutzer-Home-Ordner selbst werden nach jedem Neustart auf 777 bzw. 700 zurückgesetzt.

    Habs grad mal ausprobiert. Nach einem Neustart sind sämtliche Verzeichnisse und Files innerhalb der Benutzerordner wieder auf 777, egal wie tief in der Verzeichnisstruktur. D.h. das Verhalten hat sich nicht geändert. Kann es sein, dass UGOS mittlerweile eine Ausnahme macht für Verzeichnis .ssh?

    Wer hier Vorschläge hat, wie man das beim Start des NAS automatisieren kann, darf sich gerne hier melden.

    Weshalb das Rad neu erfinden? Die Lösung ist im Ugreen NASync Guide beschrieben und wurde hier auch bereits mehrfach erwähnt. Wer `check_and_fix_ssh_permissions.sh` bereits auf seiner NAS hat, ist klar im Vorteil. Eine Zeile im Bash Script einfügen reicht.

    Code
    # Function to set permissions
    set_permissions() {
        echo "Checking permissions..."
    
        sudo chmod 750 /home/*  # brute-forcing for all users

    Nach Zeile `echo ...` suchen und dann Zeile `sudo chmod 750 /home/*` einfügen. Done!

    Wegen der Kompatibilität zu macOS habe ich mich für exFAT entschieden (Duplicati (Suche) empfiehlt grundsätzlich NTFS oder exFAT).

    Es gibt ein relativ neues Projekt mit Namen anylinuxfs, das so ziemlich jedes Format für MacOS bereitstellt. Ich hatte noch keine Zeit mir das anzuschauen. Ev hast du ja jetzt Zeit :) für ein paar neue Experimente.

    Quote
    • mounts any filesystem supported by Linux (ext4, btrfs, xfs, ... but also NTFS and exFAT)
    • supports LUKS-encrypted drives
    • supports BitLocker-encrypted drives (using your recovery key as passphrase)
    • supports LVM (even volume groups spanning multiple drives)
    • supports LVM on LUKS (i.e. encrypted LVM)
    • supports Linux RAID

    Will ich mit Android-Handy mit VPN aus dem Datentarf heraus die DXP "wecken" (mit der App Wake of Lan von Mike Webb) klappt das nicht.

    Du hast das Problem erkannt -> VPN

    Hier nun die Erklärung dazu: WoL ist eine Broadcast Message. Ein Broadcast verlässt nie das lokale Netz. Dein Handy befindet sich in einem lokalen Netz. Dein VPN spannt ein eigenes lokales Netz auf. Dein Heimnetz spannt auch ein lokales Netz auf. Somit, vergiss es! Dein WoL Packet muss im Heimnetz generiert werden.

    Drei kleine Hiccups nach dem Firmware Update

    1. Meine /home/USER haben neu Berechtigung 700
    2. Die lokalen Docker Images in der UGOS Pro Docker App werden doppelt aufgeführt
    3. Der Workaround für nichtpulsierende LEDs ist immer noch aktiv

    Der Erst-Installations-Admin konnte keine Backups mehr machen der /home/USER Verzeichnisse. Meine Lösung ist ein chmod 750 auf allen /home/USER, eingepflegt in das bekannte check_and_fix_ssh_permissions.sh. Die doppelt geführten Images sind wahrscheinlich ein Datenbankartekfat. Jeder zweite Eintrag in dieser Liste ist ein Duplikat, ist mit einem roten Kreuz markiert. Meine Lösung: die rot markierten Images löschen (Papierkorb Icon). Der Workaround für die LEDs, falls installiert, ist immer noch aktiv. Einfach entfernen; Das Firmware Update hat den Fehler korrigiert. Bei Interesse kann ich Details zum Aufräumen liefern ;).

    Ein Blick hinter die Kulissen, mittels Linux Overlay-Filesystem (DXP4800 Plus)

    Code
    someone@icecube:~$ ls /rom/usr/bin/wg*
    /rom/usr/bin/wg  /rom/usr/bin/wget  /rom/usr/bin/wg-quick
    someone@icecube:~$ ls /overlay/upper/usr/bin/wg*
    ls: cannot access '/overlay/upper/usr/bin/wg*': No such file or directory

    Und was sagt uns das jetzt? Wireguard ist auf der UGOS-NVMe (/rom/) , wurde nicht nachträglich installiert (/overlay/upper/).

    DEPRECATED, DO NOT USE!

    UGOS Pro hat eine defekte Paketverwaltung!

    Einführung

    Homebrew ist ein Paketmanger für MacOS (und Linux). Homebrew ist minimal-invasiv. Mit brew installierte Pakete existieren in einer Parallelwelt. Die bestehende Betriebssystem-Installation wird nicht angefasst. Homebrew wurde entwickelt um neue Versionen von Kommandozeilen-Tools wie python oder rsync parallel zu bestehenden Versionen zu installieren.

    Warnung

    • Alle Angaben sind ohne Gewähr.
    • Ich hab die Installation vor mehreren Monaten gemacht und kann mich deshalb nicht mehr an die Details erinnern.
    • Homebrew ist nur für fortgeschrittene Kommandozeilen Junkies!

    Installation

    Vorbereitung

    Im GUI von UGOS PRO ein neues Administrator-Konto eröffnen für linuxbrew (ja, das ist der Name des neuen Benutzer).

    Der invasive Teil

    Via SSH auf die NAS zugreifen, mit dem regulären Administrator-Konto. Es müssen erst ein paar wenige Pakete zum bestehenden Betriebssystem hinzugefügt werden (der invasive Teil der Installation). Bei sudo wird nach dem Passwort des originalen Admins gefragt.

    Code
    sudo apt-get update
    sudo apt-get install build-essential procps curl file git

    Installation von Homebrew

    Für die Installation von Homebrew wechseln wir zum neuen Administrator.

    Code
    sudo su - linuxbrew
    /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

    Beim ersten sudo wird das Passwort des originalen Admins erwartet. Danach wird bei der Frage nach sudo das Passwort des neuen Admins linuxbrew verlangt. Optional kann nach der Installation noch der Suchpfad angepasst werden. Bitte folgende Zeile zu /home/linuxbrew/.profile hinzufügen: eval "$(/home/linuxbrew/.linuxbrew/bin/brew shellenv)"

    Aufräumen bitte!

    Nach meiner Erstinstallation hat sich Homebrew beschwert. Abhilfe schafft der Doktor.

    Code
    brew doctor
    brew update

    Im Falle einer Panikattacke

    Sollte bei obiger Installation etwas schief gehen, einfach das Installationsverzeichnis löschen und nochmals versuchen.

    Code
    # to start from scratch, delete everything
    # rm -rf /home/linuxbrew/.linuxbrew

    Hallo rsync!

    Pakete werden mit brew installiert, ohne sudo. Ausser brew fragt explizit nach sudo Rechten.

    Code
    brew install rsync

    Mittels rsync aus Homebrew lässt sich die rsync push Restriktion der System-Installation umgehen :P. Folgender Befehl transferierte meine Mediathek von einer Synology 1517 zur neuen UGreen 4800 Plus.

    Code
    # rsync push auf die 4800 Plus
    rsync -avhW --no-compress --progress --rsync-path="/home/linuxbrew/.linuxbrew/bin/rsync" \
      --exclude @eaDir MediaVault/ admin@ugnas:/volume2/MediaVault

    That's all for today, folks!