Aktuell nein. Und das "schlimme", UGOS Pro macht bei den Mountnamen keinen Unterschied zwischen internen und externen Laufwerken.
Degraded RAID, eine Platte entnommen, plötzlich waren die Externen nicht "sdc" sonder "sdb" und schon haben die Backups nicht mehr funktioniert (ohne diese neu anlegen oder umbenennen zu müssen). Erst als das RAID mit der zweiten Platte wieder repariert wurde, war alles wieder in bester Ordnung.
Auf Deine Antwort habe ich gewartet 
ich wußte Du hast Da schon mal damit herum experimentiert. Hatte aber das Ergebnis nicht mehr so im Kopf.
Knedel Wie hast du denn die Dateien exakt eingebunden in der fstab? Und wie sehen die Dateibrechtigungen des gemonteten Verzeichnisses aus?
Knedel Wie hast du denn die Dateien exakt eingebunden in der fstab? Und wie sehen die Dateibrechtigungen des gemonteten Verzeichnisses aus?
So habe ich es ans ende meiner Fstab eingefügt
UUID=B05286315285FC7A /mnt/usb1 ntfs-3g defaults,uid=1000,gid=1000,umask=000,noatime,nofail 0 0
So die gid mit 1000 sieht schon mal seltsam aus.
Was sagt den id ?
Bei mir steht beim Admin User nämlich 10.
Und was sagt ls -l für das Verzeichnis /mnt/usb1 ?
Da sollte auch dein Admin User und deine Admin Gruppe im Verzeichnis usb1 stehen, falls da root steht, sollte "other" zumindest rx als Berechtigung haben. Ich würde aber das Verzeichnis als Admin User und Gruppe ändern. Dann geht das auch mit Schreibberechtigung.
Zur Info: Da das ein NTFS Laufwerk ist, geht hier kein Backup vom NAS. NTFS unterstützt keine Linux Dateiberechtigungen, daher macht ein Backup keinen Sinn.
Da das ein NTFS Laufwerk ist, geht hier kein Backup vom NAS. NTFS unterstützt keine Linux Dateiberechtigungen, daher macht ein Backup keinen Sinn.
Hm, da habe ich gerade genau die Gegenteilige Erfahrung gemacht. Ich habe mit Sync&Backup Daten auf einen USB-Stick sichern wollen und hatte bei 2 unterschiedlichen Jobs mit jeweils anderen Daten auch das Problem der "Unklaren Fehlermeldung" und in dem Thread wurde NTFS als Lösung diskutiert und empfohlen:
Das führte auch bei mir dazu, dass das Backup schließlich durchlief. Ich will nicht sagen, dass du Unrecht hast, aber offenbar spielt das Thema "Dateiberechtigungen" nicht immer eine Rolle. Schließlich möchte ich im Zweifelsfall auf das Backup auch zugreifen können. Da ist mir das am Ende sogar lieber, als dass der Stick an einem anderen Rechner dann der Meinung ist, ich dürfte meine eigenen Daten nicht einsehen. Die Situation hatte ich nämlich schonmal und der Gedanke daran lässt mich heute noch nachts schreiend aufwachen 
(= der Grund, warum ich um diese Zeit hier noch poste )
Der NTFS Treiber unter Linux Mint erzeugt für jede Datei die Berechtigung 777. Das hab ich dieses Jahr mal auf einem USB Stick ausprobiert, wollte eigentlich mir anschauen, wie das mit dem Plattenplatzverbrauch aussieht, aber das ist mir sofort aufgefallen. exFAT hat übrigens auch 777.
Da 777 unter Linux definitv keinen Sinn macht (außer für Sonderfälle) ergibt ein Backup auch keinen Sinn. Selbst wenn das Backup und das zurückspielen funktioniert, darf dann jeder User alles. Und bei ssh mit automatischem Connect funktioniert dieser auf einmal nicht mehr, weil ssh hier die Berechtigungen überprüft. Und alle Passwort Dateien darf dann jeder verändern und löschen. Davon würde ich also absehen. Wenn man Backups von der NAS macht, dann bitte Dateisysteme nutzen, die das Berechtigungssystem unterstützen, also zum Beispiel ext4.
Ah verstehe, danke für die weitere Erläuterung. Bei ext4 meinte die KI jedoch "brauch ich gar nicht erst versuchen, funktioniert nicht mit deinen Mac-Rechnern und iPads" und das hab ich ausnahmsweise mal direkt geglaubt. Ich denke da liegt auch der Unterschied: ich würde die Daten von den Sticks vermutlich nie zurückspielen, sondern im Zweifelsfall den Stick ziehen und an einem Rechner auslesen, um auf einzelne Dateien direkt zugreifen zu können. Daher mache ich auf den Sticks auch kein versioniertes Backup. Vollständige Kopien liegen noch auf einem weiteren NAS sowie in der Cloud und von da würde ich im Zweifelsfall auch zurück sichern.
Nativ unterstützt Apple kein ext4. Worauf es mir ankommt ist, dass wenn ich das als Backup sehe und dann später Dateien zurückkopiere, dass ich dann die Berechtigungen überprüfen sollte, ob das passt, weil in diesem Fall zu viele Berechtigungen vergeben werden.
Ich habe gerade eine "freie" USB-HDD zum Testen (Duplicati) angeschlossen.
Hierüber wird als mögliches Ziel (@USB) angeboten:
In der fstab bin ich über folgenden Hinweis gestolpert:
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# systemd generates mount units based on this file, see systemd.mount(5).
# Please run 'systemctl daemon-reload' after making changes here.
#
# <file system> <mount point> <type> <options> <dump> <pass>
tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0
PARTUUID="99009e79-d999-a659-32e5-993bfb698a01" /boot vfat defaults 0 0
Mal sehen, wie weit ich damit komme
PS: wenn das jemand aus dem Ärmel schütteln kann, bin ich dankbar. Linux ist jetzt nicht gerade... 
Edit: ich habe blkid eingegeben, aber da ist erstmal nix passiert. Beim zweiten Blick stand ein Berg von IDs im Terminal. Ich stöbere...
Ich habe Rückmeldung vom Support bekommen
1. ssh-Verbindung herstellen
2. Führen Sie anschließend die folgenden Befehle aus (Beispiel):
- UUID der Festplatten anzeigen: blkid
- Mount-Punkte erstellen:
mkdir -p /mnt/backupA
mkdir -p /mnt/backupB- fstab bearbeiten:
nano /etc/fstab- Fügen Sie Einträge wie folgt ein:
UUID=xxxxx /mnt/backupA ext4 defaults,noatime,nofail 0 2
UUID=xxxxx /mnt/backupB ext4 defaults,noatime,nofail 0 2- Einstellungen sofort anwenden:
mount -a
Genau so.
So lernt man nebenbei nie aus und dazu.
alter Mann der frühe Vogel und der frische Geist...oder so ähnlich.
Ich liste mal (nicht zwingend) chronologisch auf:
Ergebnis:
Da ich bisher die Laufwerke im Wechsel genutzt und nie gleichzeitig angeschlossen habe (1NT/1Kabel, andere HDD "cold backup"), kam immer dieselbe Gerätebezeichnung raus. Jetzt mal beide, dann auch "sdd1"
Letztendlich funkt wohl der autoumount dazwischen. Evtl. helfen scripte oder udev-Regeln ("zugeworfene Begriffe"), aber dafür kenne ich zu wenig mit Linux aus.
EDIT Nachdem ich die zweite HDD angeschlossen habe, wurde die Erste "sdc1" zu "sdd1" und die neue Zweite zu "Inateck2" 🤔
Jetzt stehe ich auf dem Schlauch...
Edit2
mount -a
root@DATENSERVER:~# mount | grep @usb
/dev/sdc1 on /mnt/@usb/sdc1 type ext4 (rw,nosuid,nodev,noatime,nobarrier)
/dev/sdd1 on /mnt/@usb/sdd1 type ext4 (rw,nosuid,nodev,noatime,nobarrier)
root@DATENSERVER:~# mount | grep inateck1
/dev/sdd1 on /mnt/inateck1 type ext4 (rw,noatime,nobarrier)
root@DATENSERVER:~# mount | grep inateck2
/dev/sdc1 on /mnt/inateck2 type ext4 (rw,noatime,nobarrier)Sync & Backup
Führe ich jetzt einen Backup-Job durch, wird einen Fehlermeldung angezeigt. Musste die Laufwerke wieder auswerfen, neu starten (sdc1) und jetzt konnte ich wieder Backups durchführen.
Und was passiert, wenn Du als zusätzliche Option auto hinzufügst? Der Rest kann so bleiben.
Wird in der Dateien App sowohl als sdc1 und inateck1 erkannt.
In der Speicher App und Sync & Backup nur als eins.
HDD1 ausgeworfen, HDD2 angeschaltet:
PS: der Support meint, dass die externe HDD/Gehäuse keine UUID verwendet(?)
PPS: die Kiste läuft 24/7 und ich stecke im laufenden Betrieb nur die Laufwerke an und um
Letztendlich funkt wohl der autoumount dazwischen. Evtl. helfen scripte oder udev-Regeln ("zugeworfene Begriffe"), aber dafür kenne ich zu wenig mit Linux aus.
Lesestoff: https://www.linux-community.de/ausgaben/linux…htbarer-helfer/
*kw* zu deinem Beitrag #15!
Ich hatte eine Antwort vom UGRREN Support erhalten zu einem ähnlichen Problem, vielleicht bringt er dich ja weiter?
Bezüglich Ihres fstab-Problems möchten wir darauf hinweisen, dass manuell geänderte Konfigurationen von unserem System automatisch zurückgesetzt werden. Um dies zu verhindern, können Sie die Datei mit dem i-Attribut unveränderlich machen:
sudo chattr +i /etc/fstab
Bitte beachten Sie: Mit diesem Befehl kann das System die Datei nicht mehr ändern. Wenn Sie später neue Speicherpools erstellen oder bestehende ändern möchten, müssen Sie zunächst das Attribut wieder entfernen:
sudo chattr -i /etc/fstab
Nachdem Sie das Attribut gesetzt haben, können Sie Ihre CIFS/fstab-Einträge wie gewünscht verwenden.
Don’t have an account yet? Register yourself now and be a part of our community!
