[gelöst]Kein Zugriff auf ext. Festplatte bei Datensicherung

[ikseran]

Periodisch mache ich eine Datensicherung mit Back in Time (root). Diesmal ist kein Zugriff auf die externe Festplatte möglich. So signalisiert Back in Time

Can't write to: /run/media/... Und: Are you sure you have wright access

. Auch Deja-Dup reagiert ähnlich.
Ergänzung: Die Platte wird ins System eingebunden (MATE) und angezeigt. Darauf gespeicherte Ordner und Daten werden angezeigt, dort anderweitig hinterlegte Ordner kann ich öffnen.

Woran könnte es liegen, dass beide Programme sich so verhalten?

[sturmvogel]

Hast du denn schon propiert ob du überhaupt auf die Platte schreiben kannst? Rechtsklick->neuer Ordner zum Beispiel…

[doktor5000]

Ein bißchen wenig Details ...
Wie wurde die externe Platte gemountet, was für ein Dateisystem ist drauf, wie sehen die Rechte unter /run/media/benutzername für die Platte aus ?

[ikseran]

@ sturmvogel: Ich kann zwar einen Ordner anlegen. Will ich dies wieder rückgängig machen, kommt die Meldung, dass das Ziel schreibgeschützt ist.

@ doktor5000 Dateisystem ist ext3/ext4
Rechte:

Code: Alles auswählen

drwxr-xr-x   7 walter walter      4096 Nov 13 17:08  ./
drwxr-x---+  3 root   root          60 Nov 13 17:08  ../
drwxrwxrwx   3 root   root        4096 Mai 13  2022  backintime/
drwxr-xr-x   2 walter walter      4096 Nov 13 17:08 'Namenloser Ordner'/       (der Ordner, den ich testweise erstellt habe)

Die Frage, wie es gemountet ist, verstehe ich nicht.

[doktor5000]

Dann bitte mal die Ausgabe von

Code: Alles auswählen

mount

Der Ordner backintime gehört auf jeden Fall schonmal root:root - da dürfen zwar andere (also auch dein User) reinwechseln und schreiben, aber für Unterordner muss das nicht gegeben sein.

[ikseran]

Ausgabe von mount:

Code: Alles auswählen

proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
devtmpfs on /dev type devtmpfs (rw,nosuid,noexec,size=3973336k,nr_inodes=993334,mode=755,inode64)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,noexec,inode64)
tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,mode=755,inode64)
/dev/sda1 on / type ext4 (rw,noatime)
/dev/sda8 on /usr type ext4 (rw,noatime)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=29,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=13622)
debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime,mode=755)
tracefs on /sys/kernel/tracing type tracefs (rw,nosuid,nodev,noexec,relatime)
configfs on /sys/kernel/config type configfs (rw,nosuid,nodev,noexec,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M)
fusectl on /sys/fs/fuse/connections type fusectl (rw,nosuid,nodev,noexec,relatime)
mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime)
none on /run/credentials/systemd-sysctl.service type ramfs (ro,nosuid,nodev,noexec,relatime,mode=700)
none on /run/credentials/systemd-sysusers.service type ramfs (ro,nosuid,nodev,noexec,relatime,mode=700)
none on /run/credentials/systemd-vconsole-setup.service type ramfs (ro,nosuid,nodev,noexec,relatime,mode=700)
none on /run/credentials/systemd-tmpfiles-setup-dev.service type ramfs (ro,nosuid,nodev,noexec,relatime,mode=700)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,nr_inodes=1048576,inode64)
/dev/sdb5 on /FOTO2 type ext4 (rw,relatime)
/dev/sdb1 on /DATEN type ext4 (rw,relatime)
/dev/sda7 on /FOTO type ext4 (rw,noatime,stripe=32750)
/dev/sda6 on /home type ext4 (rw,noatime)
/dev/sda9 on /var type ext4 (rw,noatime)
none on /run/credentials/systemd-tmpfiles-setup.service type ramfs (ro,nosuid,nodev,noexec,relatime,mode=700)
tmpfs on /run/user/500 type tmpfs (rw,nosuid,nodev,relatime,size=796912k,nr_inodes=199228,mode=700,uid=500,gid=500,inode64)
portal on /run/user/500/doc type fuse.portal (rw,nosuid,nodev,relatime,user_id=500,group_id=500)
/dev/sdc2 on /run/media/walter/c59e6c32-9424-48c6-8a1f-8ac643237b3b type ext4 (ro,nosuid,nodev,relatime,errors=remount-ro,uhelper=udisks2)


[doktor5000]

/dev/sdc2 on /run/media/walter/c59e6c32-9424-48c6-8a1f-8ac643237b3b type ext4 (ro,nosuid,nodev,relatime,errors=remount-ro,uhelper=udisks2)

ro bei den Optionen heißt readonly gemountet, also nur lesend. Dateisystem könnte defekt sein.

[ikseran]

wenn ich mir die Platte in gparted anschaue, fällt auf, dass ein Schlüsselsymbol dabei steht.
Wenn ich ausgehend von mageia eine Datensicherung darauf durchführen möchte, wird mir angezeigt, dass schon ein anderes Programm darauf zugreifen würde

[doktor5000]

Das Schlüsselsymbol heißt dass die normalerweise gemountet ist.

Wenn schon ein anderes Programm drauf zugreift, dann kannst du ja einfach mittels lsof oder fuser nachschauen, welches Programm das ist.
Und wie startest du denn die Datensicherung ?

[ikseran]

Ich verwende Back in Time und starte über das Icon auf dem Desktop.
Es gibt hierzu schon einen Ordner auf dem Laufwerk, in dem sich einige Sicherungen befinden. Wenn ich starte wird im Programmfenster angezeigt, dass es eine angefangene Sicherung gibt, dann wird "in Bearbeitung" signalisiert, dann unmittelbar danach "fertig".

[doktor5000]

Und was für einen Befehl führt das Icon auf dem Desktop aus ?

[ikseran]

Code: Alles auswählen

backintime-qt

(als normaler User) oder

Code: Alles auswählen

/usr/bin/backintime-qt_polkit %f

(als root)

[doktor5000]

Wenn du das wechselweise als normaler User oder root startest, brauchst du dich auch nicht zu wundern, warum der Ziel-Ordner root gehört und du da als normaler Benutzer auch nicht reinschreiben darfst bzw. der normale User nicht auf erzeugte Sicherungen in vollem Umfang zugreifen darf.
Analog für bereits angefange Sicherungen, siehe auch https://github.com/bit-team/backintime/ ... d-warnings

[code]drwxr-xr-x 7 walter walter 4096 Nov 13 17:08 ./
drwxr-x---+ 3 root root 60 Nov 13 17:08 ../
drwxrwxrwx 3 root root 4096 Mai 13 2022 backintime/
drwxr-xr-x 2 walter walter 4096 Nov 13 17:08 'Namenloser Ordner'/ (der Ordner, den ich testweise erstellt habe)

Du solltest das mal bereinigen, entweder startest du backintime nur noch als root, dann sollte es auch keine Fehlermeldungen geben.
Oder du richtest es so ein, dass es unter dem normalen User läuft, dann muss das Ziel aber auch für den normalen User schreibbar sein.
Da du aber keine Details erwähnt hast was du eigtl. für Profile in backintime definiert hast, kann man da von remote auch kaum weiter helfen ...
Innerhalb backintime kann man sich auch das Log anzeigen lassen, hast du da mal reingeschaut ?

[ikseran]

Es scheint sehr komplex zu sein. Ich hatte bisher als root gesichert. Und es wurde ein Sicherungsvorgang unterbrochen. Es gibt im Sicherungsordner von root eine Datei mit "new snapshot". Selbst, wenn ich nun diesen Sicherungsvorgang fortsetzen möchte, wird der Vorgang gestoppt.
Im Protokoll sieht dies so aus:

Code: Alles auswählen

Last snapshot didn't finish but can be continued.

======== continue snapshot (profile 1): Mon Nov 20 19:33:16 2023 ========


Dies entspricht nicht dem Hinweis des Links von oben.

[doktor5000]

Ok, und wie wäre es mal danach zu suchen, da kommt man recht fix auf Treffer wie: https://github.com/bit-team/backintime/issues/668

Ansonsten solltest du dir vielleicht mal Gedanken um deine Sicherungsstrategie machen, verstehen wie das unter der Haube funktioniert, um das selbst zu fixen.
Jedes Backup ist nur soviel wert wie die funktionierende Rücksicherung dessen.

[ikseran]

Danke, ich werde weiter suchen.
Ich kann mir schon Gedanken machen um die "Sicherungsstrategie", aber ich komme da schnell an meine Grenzen, dies alles zu verstehen. Als Fachmann tut man sich hier vlt. schwer, dies nachzuvollziehen. Es gibt den "User".

[doktor5000]

Naja gut aber dann benutz doch eine Sicherungsstrategie die du verstehst, bringt ja nix wenn du was einsetzt was du nicht verstehst oder es im Ernstfall nicht funktioniert zum wiederherstellen.

Wie oft hast du denn schon einen Restore aus so einer Sicherung gemacht ?

[ikseran]

Bisher musste ich keinen Restore machen.

[jkowalzik]

Bisher musste ich keinen Restore machen.

Hallo!
Na, da haben wir es doch
Ich habe mir 100G in der Magenta-Cloud gegönnt, da ist alles, was ich fotografiert habe und auch was meiner schriftstellerischen Anmutung entsprungen ist drin.
Die Ehrenamtstätigkeit ist in einer anderen "Wolke", denn nur darüber läuft die Kommunikation und damit ist alles gut.
Da kann sich ein Rechner verabschieden, kommt ein neuer, MGA9-Stick rein und in wenigen Minuten kann wieder gearbeitet werden. Die "Früchte meines Denkens" sind davon unbenommen.
Fang als Erstes damit an, dass du von POP3 auf IMAP beim Postverkehr umsteigst.
Gruß
J.

[ikseran]

Fang als Erstes damit an, dass du von POP3 auf IMAP beim Postverkehr umsteigst.

, ja, das wollte ich auch schon machen. Hab' gerade ne Phase, wo ich alles mögliche reparieren muss, nicht nur am Rechner, sodass ich hierfür eher weniger Zeit verwenden kann.
Meine Fotos sind doppelt vorhanden, ebenso wichtige Dokumente. Die Datensicherung hatte ich zusätzlich vorgesehen.
Eine einfache Datensicherung scheint es bei Mageia jedoch nicht zu geben (ich will ja nicht provozieren). Ich gehe aber davon aus, dass so ein gutes System auch eine zuverlässige, von jedem User einfach zu bedienende Datensicherung haben sollte.
Ein ökologischer Aspekt: Wenn jeder in großem Umfang seine Fotos/Daten auf die Cloud schickt, müssen wir uns nicht wundern, wenn die letzten freien Flächen mit Rechenzentren zugepflastert werden. Der mittlerweile übliche Einsatz der Cloud bei Smartphonenutzern für umfangreich entstandene Fotos des täglichen Bedarfs fällt dabei schon deutlich ins Gewicht.
Aber auch hier will ich gar keine Kritik üben, sondern überlege halt für mich selbst, nicht alles auch noch irgendwo hinzuschicken und zusätzlich Rechenleistung in Anspruch zu nehmen.

[ikseran]

@jkowalzik: wobei ja 100 GB kaum ins Gewicht fallen sollten.

Ich hänge noch immer an dem Problem der nicht mehr beschreibbaren extern Festplatte.
In der Ausgabe von mount taucht dieser Eintrag zu der Platte auf:

Code: Alles auswählen

/dev/sdc2 on /run/media/walter/c59e6c32-9424-48c6-8a1f-8ac643237b3b type ext4 (ro,nosuid,nodev,relatime,errors=remount-ro,uhelper=udisks2)


Habe zwar viele Beiträge in etwa zu dem Problem durchgelesen, komme aber da nicht weiter. Wer weiß eine Lösung des Problems.

[doktor5000]

Und die Antworten dazu zuvor, die hast du schon wieder vergessen ?
Die ist wieder nur read-only also nur lesend gemountet. Einfach mal aushängen und dann als root

Code: Alles auswählen

fsck /dev/sdc2

[ikseran]

Danke. So einfach, wenn man den richtigen Befehl kennt.

Und die Antworten dazu zuvor, die hast du schon wieder vergessen ?

Das kann man so nicht sagen, auch wenn ich mittlerweile altersmäßig einiges vergesse. Dafür habe ich ja die Beiträge zum Nachschauen. Nur mein Ausgangspunkt (s.o.) bei meiner Fragestellung war vermutlich falsch, da ich davon ausging, dass es mit der Datensicherung zu tun hätte. Vermutlich aber war es eher ein unsachgemäßes Aushängen des Laufwerks, das ja im Grunde reagiert wie ein USB-Stick, wenn ich da nichts Falsches gelesen habe. Deswegen stellte ich die Frage von diesem Standpunkt aus.

Während ich dies eintippe hat tatsächlich die begonnene und gestoppte Datensicherung wieder ihre Fortsetzung gefunden.
Ich denke nicht, dass das Problem daran lag, dass ich Backintime als root ausgeführt hatte. So weit ich gesehen habe, legt root die Sicherung in eine Datei namens root innerhalb der Sicherungsdateien ab. Aber ich kann nur fabulieren.