Strato HiDrive unter Raspbian als virtuelle Festplatte einbinden

Sehr schönes Tutorial. Als Ergänzung dazu: Es gibt auch noch andere Methoden webdav unter Linux einzubinden. Vor knapp 2 Jahren hatte ich das hier zusammengefasst.

Ich habe ein Problem....
Ich führe Skriptgesteuert einen mount aus. Danach lade ich ein Backup über webdav auf einen Speicher. Am Ende des Skript kommt ein umount !! Dieses umount wartet aber nicht bis webdav die Dateien geladen hat. Gibt es da eine Möglichkeit? Mit läuft sonst immer der Cache von davfs voll !!!
Danke!!!

Zeig mal das Script

sudo –u pi mount /home/pi/cloud
tar ……. nach /home/pi/cloud
sudo –u pi umount /home/pi/cloud

Das Skript wird über Crontab gestartet!!

Ist das wirklich das vollständige Script?
Das sieht mir irgendwie nicht wie deine Beschreibung aus?
Du beschreibst das du etwas mountest - das ist die erste Zeile.
Dann beschreibst du das du ein Backup über webdev auf einen Speicher lädst - welche Zeile ist das?
Und danach wiederum beschreibst du das umount nicht warten würde bis webdev "die Datei" geladen hätte...

Kannst du bitte wirklich dein Script (in Kode) posten damit man dir auch vernünftig helfen kann?

Ansonsten frag ich mich gerade wieso du überhaupt " sudo -u pi " benutzt? Das ergibt doch irgendwie kein Sinn?

In welcher Crontab wurde das Script eingetragen?

Desweiteren solltest du vielleicht ein paar checks einbauen

Ja haste recht !!!

In sudo crontab -e

#!/bin/bash
#
# !!!! TMediaCloud Skript !!!!
#
# Konstanten
#
BACKUP_PFAD="/home/pi/cloud"
ANZAHL_BACKUPS="3"
BACKUP_NAME="xxxx"
PASSWORD="xxxx"
#
# Mount
#
sudo -u pi mount /home/pi/cloud
#
# Backup mit tar erstellen
#
tar -czf - / --one-file-system \
--exclude=${BACKUP_PFAD} \
--exclude=/proc \
--exclude=/lost+found \
--exclude=/sys \
--exclude=/mnt \
--exclude=/media \
--exclude=/dev \
--exclude=/tmp \
--exclude=/home/pi/.davfs2/cache \
| openssl des3 -salt -k ${PASSWORD} | dd of=${BACKUP_PFAD}/${BACKUP_NAME}-$(date +%Y%m%d-%H%M%S).des3
#
# Loeschen alter Backups
#
pushd ${BACKUP_PFAD}; ls -tr ${BACKUP_PFAD}/${BACKUP_NAME}* | head -n -${ANZAHL_BACKUPS} | xargs rm; popd
#
# Umount
#
sudo -u pi umount /home/pi/cloud
#

Quote from django

In sudo crontab -e

Wieso benutzt du denn "sudo crontab -e" und in dem dort eingetragenen Script wiederum nutzt du dann "sudo -u pi" ?
Merkst du nicht dass das überflüssig bzw doppeltgemoppelt ist?
Wieso sollte die Crontab vom root Benutzer ein mount als pi Benutzer ausführen?

Wieso führst du nicht einfach als "pi" Benutzer " crontab -e " aus und lässt in dem Script das "sudo -u pi" weg?

Zudem glaube ich dass das bereits dein Problem lösen müsste - die Befehle halten das Script nämlich normalerweise solange auf bis sie abgeschlossen sind..
Also erst wird gewartet bis der "mount" Befehl beendet ist, erst danach wird der tar Befehl ausgeführt und solange der beschäftigt ist macht das Script auch nicht weiter.. Und das wiederum müsste eigentlich bedeuten das der umount Befehl erst ausgeführt wird wenn auch der dadrüber stehende pushd Befehl beendet ist (ein Script wird immer von oben nach unten abgearbeitet)

Wenn das sonst tatsächlich nicht funktionieren sollte baut man eben einen Check bzw Schleife ein und prüft das vorhandensein der erstellten ${BACKUP_PFAD}/${BACKUP_NAME}-$(date +%Y%m%d-%H%M%S).des3 Datei in /home/pi/cloud/

Aber wie gesagt: lösch erstmal die crontab von root, trag das Script in die crontab vom pi Benutzer ein und entferne das "sudo -u pi" im Script..

Kann es sein dass Du eine FB 9370 als Router hast? Bei dem habe ich auch festgestellt, dass sämtliche dafs Dinge erst in den lokalen FB Cache geschrieben werden und dann asynchron auf den Cloudspace gespiegelt werden. Ich vermute mal dass da irgendwo Dein Problem liegt.

Mir ist aber noch nicht ganz klar was Du mit

Quote

Dieses umount wartet aber nicht bis webdav die Dateien geladen hat

und

Quote

Mit läuft sonst immer der Cache von davfs voll

genau meinst. Kannst Du das noch etwas genauer erklären?

Nein habe keine FB !!

1. Damit meinte ich, dass der umount Befehle den Mount aufhebt bevor die Datei vollständig hochgeladen ist.

2. In /home/pi/.davfs/cache/cloud/.... liegen die Teile der Datei die nicht hochgeladen wurden!!!

-> Mounte ich das Laufwerk von Hand so läuft der Cache langsam runter und die Datei auf der Cloud wird größe. Somit vermute ich, dass der umount den Upload unterbricht !!

Mir fällt gerade ein: Könnte es auch der Reconnect des DSL sein der den Upload unterbricht ??

Die Idee von meigraf werde ich testen!!!

Ich würds vielleicht so probiern dass das Backup erst auf einen lokalem Datenträger erstellt wird und erst nach dem vollständigen erstellen des .des3 Files auf die Cloud zu kopieren/verschieben... Dann könnte man auch vor dem "umount" eine Schleife einbauen was die tatsächliche Grösse der Datei mit der auf dem Cloud zu vergleichen und solange die Grösse nicht übereinstimmt dreht sich das Script in der Schleife und kann somit auch nicht den umount frühzeitig ausführen....

PS: Bitte gewöhn es dir ab Ausrufezeichen zu prellen (!!!), das kommt etwas aggresiv rüber - danke

So es funktioniert nun einwandfrei. Folgendes habe ich geändert:
--> Vielen Dank noch an die Antworter auf meine Frage.

1. Das Skript von sudo "crontab -e" in "crontab -e" verlagert
2. "sudo -u pi" aus dem Skript entfernt[/font][/color]
3. Das Backup auf eine andere Zeit verlegt um dem reconnect des Providers zu entgehen

Grüße

Django

Hallo boandlkramer

Dein Tutorial ist sehr gut.
Doch leider mountet mein RasPi das Hidrive nicht automatisch.
Ich habe Deine Anleitung Schritt für Schritt abgearbeitet, natürlich angepasst an meine Verhältnisse.
"mount /share/hidrive" funktioniert tadellos. Auch das umount.
Selbige Anleitung hab ich auch in Ubuntu 14.04 eingearbeitet. Dort läuft es einwandfrei.
Nur auf dem Pi nicht.
Das System ist auf aktuellem Stand.
In der fstab steht folgender Eintrag:
"https://Benutzername.webdav.hidrive.strato.com/ /share/hidrive davfs noauto,user 0 0"
In der ~/.davfs2/secrets steht folgendes (ebenso in der /etc/davfs2/secrets):
"https://Benutzername.webdav.hidrive.strato.com Benutzername StrengGeheim"

Hier mal die Ausgabe von mount unmittelbar nach Systemstart:
pi@raspberrypi ~ $ mount
/dev/root on / type ext4 (rw,noatime,data=ordered)
devtmpfs on /dev type devtmpfs (rw,relatime,size=215824k,nr_inodes=53956,mode=755)
tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=44820k,mode=755)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /run/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=89620k)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620)
/dev/mmcblk0p1 on /boot type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro)
/dev/sda1 on /share type ext4 (rw,relatime,data=ordered)

und hier nach "handmount":

pi@raspberrypi ~ $ mount /share/hidrive
pi@raspberrypi ~ $ mount
/dev/root on / type ext4 (rw,noatime,data=ordered)
devtmpfs on /dev type devtmpfs (rw,relatime,size=215824k,nr_inodes=53956,mode=755)
tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=44820k,mode=755)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /run/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=89620k)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620)
/dev/mmcblk0p1 on /boot type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro)
/dev/sda1 on /share type ext4 (rw,relatime,data=ordered)
https://Benutzername.webdav.hidrive.strato.com/ on /share/hidrive type fuse (rw,nosuid,nodev,noexec,relatime,user_id=1000,group_id=1000,allow_other,max_read=16384)
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
pi@raspberrypi ~ $

Ich kann auf dem eingehängten HiDrive vom Pi aus auch schreiben.

Was mache ich falsch?

Grüße

HansHiasl

Update!

Der Eintrag in die rc.local

sleep 30
mount -a

hat das Problem gelöst.
Offensichtlich stand zum Mountzeitpunkt die Netzwerkverbindung noch nicht zur Verfügung.

Jetzt ist es gut :-))