[mount] Probleme mit Zugriffsrechten auf alte Backups

[buhtz]

Ich hab mit einer anderen Maschine (Ubuntu Trusty) Dateien auf einem samba-share abgelegt.
Dafür wurde "backintime" genutzt, was wiederum IMO rsync verwendet. Das mounten der samba-shares habe ich dabei mit einem eigenen script erledigt.

Jetzt mit Siduction habe ich Probleme auf diese Dateien voll zuzugreifen.

Hier mal ein Überblick:

Code Auswählen Erweitern


user@TONNE:/mnt/Sparky$ ll
insgesamt 12
drwxr-xr-x 2 root root 4096 Jul 24 09:29 Backup/
drwxr-xr-x 2 root root 4096 Jul 24 09:29 Multimedia/
drwxr-xr-x 2 root root 4096 Jul 24 09:29 Pictures/

user@TONNE:/mnt/Sparky$ cat /etc/fstab | grep Backup
//SPARKY/Backup     /mnt/Sparky/Backup     cifs rw,credentials=/home/user/.cred_sparky_backup,noauto,user 0 0

user@TONNE:/mnt/Sparky$ mount Backup

user@TONNE:/mnt/Sparky$ ll Backup/backintime/TONNE/user
insgesamt 0
drwxr-xr-x 2 user user 0 Jul 22 22:32 1/
drwxr-xr-x 2 user user 0 Jul 22 22:45 2/
drwxr-xr-x 2 user user 0 Jul 11 15:05 3/
drwxr-xr-x 2 user user 0 Jul 22 18:57 5/
drwxr-xr-x 2 user user 0 Okt  4  2015 6/

user@TONNE:/mnt/Sparky$ ll Backup/backintime/TONNE/user/1
insgesamt 0
drwxr-xr-x 2 user user 0 Nov 30  2015 20151130-100009-806/
drwxr-xr-x 2 user user 0 Dez 28  2015 20151228-180309-722/
drwxr-xr-x 2 user user 0 Jan 26  2016 20160126-150459-475/
drwxr-xr-x 2 user user 0 Feb 26 19:37 20160226-193612-821/
drwxr-xr-x 2 user user 0 Mär 28 17:01 20160328-170016-537/
drwxr-xr-x 2 user user 0 Apr 26 17:08 20160426-170644-890/
drwxr-xr-x 2 user user 0 Mai  2 00:02 20160502-000005-241/
drwxr-xr-x 2 user user 0 Mai  9 15:01 20160509-150003-596/
drwxr-xr-x 2 user user 0 Mai 21 17:47 20160521-174304-500/
drwxr-xr-x 2 user user 0 Mai 29 09:31 20160529-093002-964/
drwxr-xr-x 2 user user 0 Jun  2 06:46 20160602-064502-874/
drwxr-xr-x 2 user user 0 Jun 10 02:18 20160610-021611-890/
drwxr-xr-x 2 user user 0 Jun 18 19:32 20160618-193003-507/
drwxr-xr-x 2 user user 0 Jun 26 09:32 20160626-093002-377/
drwxr-xr-x 2 user user 0 Jun 30 19:35 20160630-193346-220/
drwxr-xr-x 2 user user 0 Jul  8 00:02 20160708-000002-726/
drwxr-xr-x 2 user user 0 Jul 12 18:31 20160712-183003-580/
drwxr-xr-x 2 user user 0 Jul 16 22:32 20160716-223002-542/
drwxr-xr-x 2 user user 0 Jul 21 16:20 20160721-161835-204/
drwxr-xr-x 2 user user 0 Jul 22 18:59 20160722-185809-239/
drwxr-xr-x 2 user user 0 Jul 22 22:32 20160722-223051-183/
drwxr-xr-x 2 user user 0 Jul 22 22:32 last_snapshot/

user@TONNE:/mnt/Sparky$ touch Backup/backintime/TONNE/user/1/test.file
touch: 'Backup/backintime/TONNE/user/1/test.file' kann nicht berührt werden: Keine Berechtigung

user@TONNE:/mnt/Sparky$ ll Backup/backintime/TONNE/user/1/last_snapshot
insgesamt 28
drwxr-xr-x 2 user user     0 Jul 15 15:10 backup/
-rwxr-xr-x 1 user user 26322 Jul 22 22:32 config*
-rwxr-xr-x 1 user user   155 Jul 22 22:32 info*
-rwxr-xr-x 1 user user  1131 Jul 22 22:32 takesnapshot.log.bz2*

user@TONNE:/mnt/Sparky$ ll Backup/backintime/TONNE/user/2/last_snapshot/backup/home/user
insgesamt 0
drwxr-xr-x 2 user user 0 Jul 18 07:08 share/

user@TONNE:/mnt/Sparky$ touch Backup/backintime/TONNE/user/2/test.file
touch: 'Backup/backintime/TONNE/user/2/test.file' kann nicht berührt werden: Keine Berechtigung


Ich kann also die Dateien sehen und sogar lesen. Ich kann aber nichts schreiben - keine neuen Dateien und keine alten Dateien.

Wie sollte ich nun vorgehen, um da wieder schreiben zu können?

Was mich irritiert: Unter Ubuntu Trusty habe ich die gleiche /etc/fstab Zeile verwendet - nur ohne den Zusatz "user". Unter Trusty konnte ich als einfacher user das share mounten. Auch bei dem Backup mit backintime wurde das share als einfacher user gemountet und beschrieben.

Am NAS hat sich nix geändert. Der user dort heißt "backup" (ist so in den credentials auch eingetragen) und hat Lese-/Schreibrechte.

[unklarer]

Ich habe das gestern schon einmal gelesen und da hier noch keiner geantwortet hat, will ich das tun ohne eine Lösung zu bieten.   

Jetzt mit Siduction habe ich Probleme auf diese Dateien voll zuzugreifen.
...
Wie sollte ich nun vorgehen, um da wieder schreiben zu können?

Vielleicht im Wiki oder Handbuch nachsehen, wie das siduction macht und nicht die Krücken der beiden Anderen.
Ist das ein Anfang?:  http://manual.siduction.org/samba#configure

[buhtz]

Hi unklarer.
Ich habs gelesen, jedoch ist da nix, was ich nicht schön wüsste - abgesehen vom Server-Teil.

Bin nicht sicher, ob ich mein Problem hier richtig rübergebracht habe?

Ich kann das share mounten und ich kann darauf schreiben.
Ich kann aber nicht bestehende Dateien/Ordner, die sich schon auf diesem share befinden, schreiben.

Sehr auffällig ist, dass das Problem nur bei Daten auftritt, die mit rsync dort abgelegt wurden.
rsync hat aber definitiv nur "lokal" mit mount-points gearbeitet und nicht mit einem rsync-deamon auf der anderen Maschine!

Diese bereits bestehenden Daten wurden mit einer anderen Maschine (Ubuntu Trusty) angelegt.

Irgendwie gibt es da Probleme mit den Zugriffsrechten und ich würde die Dateien gerne wieder nutzen können (per mount-point und nicht per smb://).

[melmarker]

Dann schau Dir doch mal die Rechte an.

[buhtz]

Dann schau Dir doch mal die Rechte an.

Du meinst beispielsweise?

Code Auswählen Erweitern

drwxr-xr-x 2 user user 0 Jul 22 22:32 1/

Ich sehe das "user" vollen Zugriff hat. Scheinbar bin ich ("user") nicht der "user" der dort angezeigt wird? Kann man sich die vom System genutzen Zahlenwerte/ID für den Benutzernamen anzeigen lassen?, um das mal zu vergleichen?


Da komme ich doch auf die Idee mal auf das NAS direkt (per SSH shell) zu schauen.
Dort sehe ich z.B. sowas

Code Auswählen Erweitern

[/share/Backup/backintime/TONNE/user] # ls -l
drwxrwxr-x   23 1000     1000          4096 Jul 22 22:32 1/

[wannek3]

-n statt -l bei ls listet die UID/GID

Schreiben (und Löschen) in Verzeichnisse hängt an den Rechten des übergeordneten Verzeichnises, vielleicht hapert es da in der Kette?

Code Auswählen Erweitern

namei -lm /home/user/bla.txt

[buhtz]

Code Auswählen Erweitern

$ ll /mnt/Sparky/Backup/backintime/TONNE/user/2
insgesamt 0
drwxr-xr-x 2 user user 0 Aug 31  2015 20150831-103002-683/
drwxr-xr-x 2 user user 0 Sep 29  2015 20150929-180003-130/
drwxr-xr-x 2 user user 0 Okt 31  2015 20151031-181502-622/
...SNIPPED...
drwxr-xr-x 2 user user 0 Jul 22 18:50 last_snapshot/

$ namei -lm /mnt/Sparky/Backup/backintime/TONNE/user/2
f: /mnt/Sparky/Backup/backintime/TONNE/user/2
drwxr-xr-x root root /
drwxr-xr-x root root mnt
drwxr-xr-x root root Sparky
drwxr-xr-x user user Backup
drwxr-xr-x user user backintime
drwxr-xr-x user user TONNE
drwxr-xr-x user user user
drwxr-xr-x user user 2

Kette? Das heißt doch aber wahrscheinlich nicht, dass ich / auf "user" umbiegen soll, oder?

[bluelupo]

Hi buhtz,

mit welchen User willst du auf die Backups zugreifen. Poste bitte als dieser User die Ausgabe von "id -a".

[wannek3]

Rechte sehen gut aus, sorry, keine Idee.

Hirngespinste:

   
• Können zwei User gleiche Namen haben?
• Läuft Selinux (ich sehe keine Punkte)
• Geht samba-mount durch eine Firewall?
• verbieten die credentials intern Änderungen?

Mein einziges samba geht so:

Code Auswählen Erweitern

sudo mount.cifs //SHARE  /mnt -o user=NAME,uid="$(id -u)",gid="$(id -g)"

[buhtz]

mit welchen User willst du auf die Backups zugreifen. Poste bitte als dieser User die Ausgabe von "id -a".

Code Auswählen Erweitern

$ id -a
uid=1000(user) gid=1000(user) Gruppen=1000(user),7(lp),20(dialout),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),46(plugdev),100(users),101(systemd-journal),109(lpadmin),112(netdev),115(scanner)

Mit "welchem User"? Aus Sicht meines Siductions (der samba-client) oder aus Sicht des NAS (der samba-server)?
Nach meinem Verständnis:
Das share auf dem NAS wird als Benutzer "backup" gemountet. Dieser Nutzer existiert auf dem NAS und wird über die credentials angegeben.
Wenn es dann gemountet ist, werkle ich als Benutzer "user" auf meinem Siduction. Das ist der "normale" Linux-Siduction-Benutzer hier auf meinem PC.

Können zwei User gleiche Namen haben?

Soweit ich weiß ja. Der String des Usernamens ist nur ein alias, die tatsächliche Identität bestimmt die dahinterstehende Nummer/id.

Läuft Selinux (ich sehe keine Punkte)

Kenne ich nur vom hören sagen. Wenn es nicht per default bei Siduction aktiviert ist, läuft es nicht. Wie kann ich das prüfen?

Geht samba-mount durch eine Firewall?

Nein. Client und Server sind hier zu Hause in meinem privaten Normalo-Netz, das die FritzBox managed - nix besonderes.

verbieten die credentials intern Änderungen?

Was meinst du mit "interne Änderungen"? Der durch die credentials bestimmte Nutzer "backup" hat Lese-/Schreibrechte auf dem Share.

Das habe ich auf der WebOberfläche des QNAP-NAS so eingestellt. Was da im Hintergrund genau passiert, kann ich nicht sagen.

Wie eingangs gesagt: Früher hat das alles funktioniert.

Mein Hirngespinst:
Die Daten auf die ich hier nicht zugreifen kann, wurden mit rsync angelegt. könnte es sein, dass auf dieser Ebenen etwas nicht so ganz korrekt gelaufen ist?
Habe daher mal kurz testweise ein eigenes rsync mit einem Testverzeichnis laufen lassen. Funktioniert ohne Probleme. So lässt es sich also nicht reproduzieren.

Nochmal zusammengefasst:
Es scheint einen Zusammenhang mit dem (nicht mehr existenten) Ubuntu zu liegen.
Die Daten auf die ich jetzt nicht mehr zugreifen kann, wurden mit zwei Methoden auf das NAS geschaufelt:

   
• Backintime (was intern rsync nutzt)
• und einem von mir selbst erstellten rsync-script

Nur 2 habe ich gerade nochmal (mit gleichen Optionen/Schaltern), diesmal unter Siduction, mit einem kleinen Testverzeichnis laufen lassen. Dabei kann ich das Problem nicht reproduzieren.
Versuche ich mit Backintime unter Siduction die bestehenden (oben genannten) Backup-Verzeichnis weiterzunutzen (was auch so vorgesehen ist in Backintime) bekomme ich die Fehlermeldung mit den Schreibrechten.
Beide Erfahrungen/Tests bringen mich zu der Theorie, dass es an einem Unterschied zwischen Ubuntu und Siduction liegen könnte.
Und jetzt kommts: Unter Ubuntu sah die fstab-Zeile so aus.
//SPARKY/Backup /mnt/Sparky/Backup cifs rw,credentials=/home/user/.cred_sparky_backup,noauto 0 0
Unter Siduction sieht sie so aus
//SPARKY/Backup     /mnt/Sparky/Backup     cifs rw,credentials=/home/user/.cred_sparky_backup,noauto,user 0 0
Hier ist das "user" neu hinzugekommen. Ohne diese Option war es mir ncht möglich in Siduction den Befehl "mount" als einfacher Benutzer auszuführen. Unter Ubuntu konnte ich das - bilde ich mir jedenfalls ein.
Hängt es vielleicht an dieser kleinen Option?

[bluelupo]

Hi buhtz,

nein mit der "user" Option hat dies nichts zu tun, sondern mit den Zugriffsrechten. Wenn die UserID (nicht der Name) des Dateiowners passt solltest du zugreifen können.

Was sagt den...

Code Auswählen Erweitern

$ stat dateiname
...zu so seiner Datei?

[buhtz]

Schwierig. Dateien dort kann ich ja lesen. Aber ich kann nichts neues in die Verzeichnisse schreiben. Sorry, da hatte ich mich eingangs unklar ausgedrückt.

Code Auswählen Erweitern

$ mount /mnt/Sparky/Backup
$ namei -lm /mnt/Sparky/Backup/backintime/TONNE/user/1/last_snapshot
f: /mnt/Sparky/Backup/backintime/TONNE/user/1/last_snapshot
drwxr-xr-x root root /
drwxr-xr-x root root mnt
drwxr-xr-x root root Sparky
drwxr-xr-x user user Backup
drwxr-xr-x user user backintime
drwxr-xr-x user user TONNE
drwxr-xr-x user user user
drwxr-xr-x user user 1
drwxr-xr-x user user last_snapshot

$ ll -n /mnt/Sparky/Backup/backintime/TONNE/user/1/last_snapshot
insgesamt 28
drwxr-xr-x 2 1000 1000     0 Jul 15 15:10 backup/
-rwxr-xr-x 1 1000 1000 26322 Jul 22 22:32 config*
-rwxr-xr-x 1 1000 1000   155 Jul 22 22:32 info*
-rwxr-xr-x 1 1000 1000  1131 Jul 22 22:32 takesnapshot.log.bz2*
$ ll /mnt/Sparky/Backup/backintime/TONNE/user/1/last_snapshot
insgesamt 28
drwxr-xr-x 2 user user     0 Jul 15 15:10 backup/
-rwxr-xr-x 1 user user 26322 Jul 22 22:32 config*
-rwxr-xr-x 1 user user   155 Jul 22 22:32 info*
-rwxr-xr-x 1 user user  1131 Jul 22 22:32 takesnapshot.log.bz2*

$ touch /mnt/Sparky/Backup/backintime/TONNE/user/1/last_snapshot/meinedatei
touch: '/mnt/Sparky/Backup/backintime/TONNE/user/1/last_snapshot/meinedatei' kann nicht berührt werden: Keine Berechtigung

$ cat /mnt/Sparky/Backup/backintime/TONNE/user/1/last_snapshot/info
...SNIPPED...DATEIINHALT...

$ stat /mnt/Sparky/Backup/backintime/TONNE/user/1/last_snapshot
  Datei: '/mnt/Sparky/Backup/backintime/TONNE/user/1/last_snapshot'
  Größe: 0             Blöcke: 0          EA Block: 16384  Verzeichnis
Gerät: 2dh/45d    Inode: 126238723   Verknüpfungen: 2
Zugriff: (0755/drwxr-xr-x)  Uid: ( 1000/    user)   Gid: ( 1000/    user)
Zugriff    : 2016-08-05 22:13:43.691171200 +0200
Modifiziert: 2016-07-22 22:32:50.621497600 +0200
Geändert   : 2016-07-22 22:32:50.621497600 +0200
Geburt    : -

$ stat /mnt/Sparky/Backup/backintime/TONNE/user/1/last_snapshot/info
  Datei: '/mnt/Sparky/Backup/backintime/TONNE/user/1/last_snapshot/info'
  Größe: 155           Blöcke: 1          EA Block: 16384  reguläre Datei
Gerät: 2dh/45d    Inode: 367         Verknüpfungen: 1
Zugriff: (0755/-rwxr-xr-x)  Uid: ( 1000/    user)   Gid: ( 1000/    user)
Zugriff    : 2016-08-06 14:33:56.729270900 +0200
Modifiziert: 2016-07-22 22:32:50.605497600 +0200
Geändert   : 2016-07-22 22:32:50.605497600 +0200
Geburt    : -

Nebenbei: Eingangs hatte ich fälschlich behauptet ein Zugriff über smb:// wäre problemlos möglich. Das ist nicht korrekt. per smb:// hatte ich mich routinemäßig immer als admin am NAS angemeldet. Da geht alles. Melde ich mich aber als "backup" (also der user, der auch bei mount verwendet wird), habe ich die gleichen Probleme.

[melmarker]

Wie wäre es mit diesem Vorschlag: If anything else fails, read the fucking manual! - Ich glaub, das wäre jetzt mal an der Zeit. Und dann machst Du da ne ordentliche und vor allem richtige Konfiguration von, dokumentiertst das ordentlich und lebst mit dieser Lösung bis ans Ender der Tage dieser Installation?