Problem bei Datensicherung

Hallo,

ich habe auf einem Rechner ein merkwürdiges Phänomen. Vielleicht weiß jemand Rat. Die Daten von UserName sollen mit Hilfe eines Scriptes gesichert werden.

/home hat drei Unterverzeichnisse:

**
UserName**
backup
lost+found

Das Backup-Verzeichnis liegt in einer eigenen Partition auf anderen Platte (auf diesem Rechner - hier klappt es - auf derselben Platte).


rsync -abuv --progress /home/**UserName** /home/backup 
find /tmp -maxdepth 1 -mindepth 1 -print0 | xargs -0r rm -rf
read

Aber offenbar ist irgendwo der Wurm drin:


sending incremental file list 
rsync: recv_generator: mkdir "/home/backup/**UserName**" failed: Permission  denied (13) 
*** Skipping any contents from this failed directory *** 
**UserName**/ 

Number of files: 33,530 (reg: 31,732, dir: 1,790, link: 8) 
Number of created files: 1 (dir: 1) 
Number of deleted files: 0 
Number of regular files transferred: 0 
Total file size: 28,604,158,411 bytes 
Total transferred file size: 0 bytes 
Literal data: 0 bytes 
Matched data: 0 bytes 
File list size: 720,768 
File list generation time: 0.001 seconds 
File list transfer time: 0.000 seconds 
Total bytes sent: 1,304,889 
Total bytes received: 2,100 

sent 1,304,889 bytes  received 2,100 bytes  871,326.00 bytes/sec 
total size is 28,604,158,411  speedup is 21,885.54 
rsync error: some files/attrs were not transferred (see previous errors)  (code 23) at main.c(1165) [sender=3.1.0] 

--------------------------------------------------------------------------- 
Taste <ENTER> drücken um Sicherungslauf zu beenden

Ich habe die File-/Verzeichnis-Berechtigungen kontrolliert, sieht alles unverdächtig aus. Was kann das Problem sein?
Auf dem Rechner, auf dem ich gerade schreibe, mache ich im Grunde dasselbe (nur anderer UserName), und alles läuft.

LG

Welches Dateisystem benutzt du für /home/backup?
Und wie sind die Verzeichnisberechtigungen von /home/backup genau?

ls -l /home/

Scheinbar hat dein Benutzer auf diesem Rechner Schreibzugriff, der auf dem anderen Rechner nicht.

Vermutlich haben die beiden Benutzer eine unterschiedliche User-Id, also poste die bitte auch für beide Rechner:

id

Dieser Rechner:

linux-7jgt:~ # df -h -T
Filesystem     Type      Size  Used Avail Use% Mounted on
/dev/sda2      ext4       20G  6.0G   13G  32% /
devtmpfs       devtmpfs  933M   16K  933M   1% /dev
tmpfs          tmpfs     944M  224K  944M   1% /dev/shm
tmpfs          tmpfs     944M   15M  930M   2% /run
tmpfs          tmpfs     944M     0  944M   0% /sys/fs/cgroup
tmpfs          tmpfs     944M   15M  930M   2% /var/run
tmpfs          tmpfs     944M   15M  930M   2% /var/lock
/dev/sda3      ext4       29G  7.2G   21G  26% /home
/dev/sda4      ext4       23G   11G   12G  48% /home/backup


linux-7jgt:~ # ls -l /home/
total 24
drwxr-xr-x  4 root     root   4096 Apr  6  2014 backup
drwx------  2 root     root  16384 Apr  2  2014 lost+found
drwxr-xr-x 50 UserName users  4096 Feb 26 14:00 UserName


linux-7jgt:~ # id
uid=0(root) gid=0(root) groups=0(root)


linux-7jgt:~ # id UserName
uid=1000(UserName) gid=100(users) groups=100(users)

Bei dem anderen Rechner kann ich im Moment niemand erreichen. Melde mich dann wieder.

Tja, wie du sehen kannst, hat nur root Schreibzugriff auf /home/backup.
Du rufst rsync also scheinbar als root auf (die Ausgabe von “id” bestätigt dass du als root eingeloggt bist).
Am anderen Rechner wirds vielleicht als normaler Benutzer ausgeführt?

Bei dem anderen Rechner kann ich im Moment niemand erreichen. Melde mich dann wieder.

Ok.

Tja, wie du sehen kannst, hat nur root Schreibzugriff auf /home/backup.
Du rufst rsync also scheinbar als root auf (die Ausgabe von “id” bestätigt dass du als root eingeloggt bist).
Am anderen Rechner wirds vielleicht als normaler Benutzer ausgeführt?

Den Verdacht hatte ich auch, aber dem ist nicht so.
Ich rufe das Ding auf diesem Rechner mit UserName auf, und es wird ausgeführt.
Das Script gehört auch UserName (Gruppe users).

Es gibt ein Icon auf dem “Schreibtisch” auf dem “Desktop”, das wird einfach angeklickt, bevor man die Kiste runterfährt, dann wird das Shellscript aufgerufen und ausgeführt.

Ich bin mir fast sicher, dass das bei dem anderen Rechner auch so ist, wir hatten am Samstag, als ich da war, dieses Problem, und ich erinnere mich, dass ich mir Berechtigungen angeschaut habe.
Es lief monatelang ohne dieses Berechtigungsproblem, erst nachdem der Inhalt des Shell-Scriptes wegen eines Fehlers geändert worden war, gibt es dieses Problem.

Es ist egal, wem das Skript gehört.
Wichtig ist nur als welcher Benutzer du eingeloggt bist, wenn du es aufrufst.
Das “id” vorhin sagt “root”, also hat das Skript Schreibzugriff.

Rufe folgendes auf, und jeder Benutzer sollte nach /home/backup schreiben können:

sudo chmod a+w /home/backup

So, das Ergebnis von dem anderen Rechner:

linux-fixp:~ # df -h -T 
Filesystem     Type      Size  Used Avail Use% Mounted on 
/dev/sda2      ext4       20G  9.0G  9.6G  49% / 
devtmpfs       devtmpfs  744M   32K  744M   1% /dev 
tmpfs          tmpfs     756M  144K  755M   1% /dev/shm 
tmpfs          tmpfs     756M  3.0M  753M   1% /run 
tmpfs          tmpfs     756M     0  756M   0% /sys/fs/cgroup 
tmpfs          tmpfs     756M  3.0M  753M   1% /var/run 
tmpfs          tmpfs     756M  3.0M  753M   1% /var/lock 
/dev/sda3      ext4      125G   27G   97G  22% /home 


linux-fixp:~ #   ls -l */home/ 
total 24 
drwxr-xr-x  2 root   root   4096 Feb  7 17:39 backup 
drwx------  2 root   root  16384 Mar 29  2014 lost+found 
drwxr-xr-x 32 *User2* users  4096 Feb 26 18:18 *User2*


linux-fixp:~ # id 
uid=0(root) gid=0(root) groups=0(root) 


linux-fixp:~ # id *User2*
uid=1000(User2) gid=100(users) groups=100(users) 
*

In dem Fall ist kein /home/backup gemountet, es wird also auf die /home Partition geschrieben.
Das ist aber schon so gewünscht, oder?

linux-fixp:~ # ls -l */home/
total 24
drwxr-xr-x 2 root root 4096 Feb 7 17:39 backup
drwx------ 2 root root 16384 Mar 29 2014 lost+found
drwxr-xr-x 32 User2 users 4096 Feb 26 18:18 User2
*

Tja, wie vorher: nur root kann nach /home/backup schreiben.
Das Skript muss daher als root ausgeführt werden. Auch hier würde “id” aber sagen, dass der aktuelle Benutzer root ist.

Also, wenn das Skript tatsächlich als root läuft und trotzdem “Permission denied” bekommnt, dann kann eigtl. nur das Dateisystem beschädigt sein.
Probiert mal fsck drüber laufen zu lassen.

Allerdings postest du ja in deinem Ursprungspost:

sending incremental file list 
rsync: recv_generator: mkdir "/home/backup/UserName" failed: Permission  denied (13) 
*** Skipping any contents from this failed directory *** 
UserName/ 

Du schreibst aber, dass es auf diesem Rechner (mit UserName) klappt, auf dem anderen mit “User2” nicht. Sollte dann in der Fehlermeldung nicht “User2” stehen?
Irgendwie bin ich mir jetzt nicht ganz sicher ob ich das Problem korrekt verstehe…

In dem Fall ist kein /home/backup gemountet, es wird also auf die /home Partition geschrieben.
Das ist aber schon so gewünscht, oder?

Nee, ganz sicher nicht. Es sollte eigentlich ein /home/backup-Verzeichnis geben. Das ist merkwürdig.

Allerdings hatten wir mit dem Rechner und dem speziell der Backup-Platte letztens ein Problem, es gibt einen anderen Artikel hier dazu. Dass die Partition wieder verschwunden ist, würde erklären, warum es plötzlich nicht mehr klappt, obwohl es vorher die ganze Zeit, wenn auch mit zuviel Daten, geklappt hat.

Du schreibst aber, dass es auf diesem Rechner (mit UserName) klappt, auf dem anderen mit “User2” nicht. Sollte dann in der Fehlermeldung nicht “User2” stehen?

Eigentlich ja, obwohl der richtige Name noch ein anderer ist. Es sollte nur möglichst anonym sein.

Das werde ich nicht telefonisch machen, ich melde mich dann noch einmal.

Danke Dir mal erst, Du bist mir/uns wirklich eine sehr große Hilfe!

Und wie funktionirt das? NFS vielleicht?
Wenn ja, dann hat root auf dem client system keine besondere Rechte. Eher weniger.
Aus Siecherheitsgründe. Wenn man ein teil seines System exporiert, heiß dat nicht automatisch das man den Manager des client Systems gleich Manager seines eigenes System machen möchte. (Ist aber configurierbar).

Sollte ebenalls ext4 sein, wenn ich nicht irre.

Wie gesagt, es hat ja funktioniert. Aber bei irgendeinem Suse-Update (hier der Artikel) letztens ist irgendetwas passiert, seitdem haben wir diesen Schlamassel.

Samstag in einer Woche weiß ich mehr.