[Problem] Fritzbox - Online-Speicher - Upload nicht möglich

pimperding

Neuer User
Mitglied seit
27 Nov 2013
Beiträge
5
Punkte für Reaktionen
0
Punkte
0
Schönen guten Tag,

habe auf meiner Fritzbox 7360 den Online-Speicher aktiviert und hierfür die Zugangsdaten zu einem eigenen externen Apache2 (2.2.22) mit mod_dav eingetragen. Der Zugriff auf diesen Speicher über die NAS-Oberfläche der Fritzbox ist auch möglich, nur

- der unter der Webdav-Freigabe verfügbare Speicherplatz wird in der NAS-Oberfläche der Fritzbox nicht angezeigt (im Gegensatz zu dem Speicherplatz, der auf dem an die Fritzbox angeschlossenen USB-Stick verfügbar ist) und

- der Upload von Dateien wird mit der Fehlermeldung "Nicht genügend freier Speicherplatz auf dem Ziellaufwerk" quitiert, obwohl auf diesem Laufwerk hinreichend viel Speicherplatz verfügbar ist.

In den Logdateien des Apache2 finden sich keine Fehlermeldungen, der Speicher ist mit anderen DAV-Clients (z.B. Cadaver) auch mit den Anmeldedaten beschreibbar, die ich in der Fritzbox hinterlegt habe. Weiß nicht weiter. Hat jemand vielleicht einen Tip für mich?

Dank und Gruß
Stephan
 
Moin

Das ist schon richtig so.
Die 7360SL hat ca 300Kb als: /var/media/ftp
Du musst dem Benutzer des NAS nicht...
Alle an der FRITZ!Box verfügbaren Speicher
...sondern ein Laufwerk oder ein Vereichnis im Laufwerk zuteilen.
Dann landest du mit FTP Login auch in diesem, und da hast du dann auch
genug Speicher der auch richtig berechnet wird.

Auch kann es sein, dass der Root mit 1Kb angezeigt wird...
Frei: 0 Byte von 1 Byte
...wenn es so ist, erst in ein anderes Verzeichnis wechseln.
Dann wird der Speicherplatz wieder korrekt berechnet.

Wird wohl wieder ein Bug der Firmware sein.
An AVM melden, zum Beheben.
 
Zuletzt bearbeitet:
Besten Dank. Ich weiß leider nicht, ob ich das richtig verstehe. Zuerst ein paar Zusatzinformationen, die ich in meinem Posting oben vergessen habe:

- Fritzbox 7360 DE 124.06.20 (Artikelnummer 2000 2522)
- Online-Speicher auf eigenem externen Apache2 (2.2.22) mit mod_dav mit ca. 150 GB Speicherplatz.

Die NAS-Oberfläche der Fritzbox, in der sowohl der USB-Stick als auch der Online-Speicher erscheint, zeigt "Frei: 54,46 MB von 55,58 MB". Beim Wechsel in das Verzeichnis des USB-Sticks in der NAS-Oberfläche wird richtigerweise angezeigt, dass "Frei: 3,02 GB von 3,72 GB". Beim Wehcsel in das Verzeichnis des Online-Speichers wird zum verfügbaren Speicherplatz überhaupt nichts angezeigt und der Upload von Dateien scheitert mit der o.g. Fehlermeldung. Wenn ich in der NAS-Oberfläche der Fritzbox in ein tieferes Verzeichnis des Online-Speichers wechsele, wird der insgesamt verfügbare Speicherplatz auch nicht angezeigt, und der Upload funktioniert auch dort nicht. Zum vergleich: Wenn ich einen anderen, kommerziellen Webdav-Speicher (wie z.B. Telekom) in der Fritzbox eintrage, funktioniert beides, d.h. sowohl der Upload von Dateien als auch die Anzeige des insgesamt auf dem Webdav-Laufwerk verfügbaren Speichers.

Wenn ich neue Fritzbox-Benutzer anlege und ihnen Zugriff auf ein bestimmtes Verzeichnis auf dem NAS geben möchte, erscheinen zur Auswahl die Alternativen "Alle an der FRITZ!Box verfügbaren Speicher" und "Verzeichnis wählen". Unter letzterem findet sich dann aber nur das Verzeichnis des USB-Sticks. Das Verzeichnis des Online-Speichers erscheint dort nicht.

Ein df -h auf der Fritzbox zeigt sowohl den USB-Stick als auch den Online-Speicher mit jeweils 3,72 GB, was ja der Gesamtgröße des USB-Sticks entspricht.

Sollte ich mich damit an AVM wenden?

Dank und Gruß
Stephan
 
Ich würde das gerne nachstellen.
Kannst du mir die dafür notwendigen Konfigurationsschritte des Apaches und der Fritz!Box
(Anonymisiert) zeigen?
Dann konfiguriere ich meinen Apache auf den Raspberry Pi mal als Onlinespeicher.
Vielleicht finden wir so eine Lösung zusammen.
 
Gern, besten Dank. Der Apache (2.2.22) läuft auf einem Raspberry Pi mit Raspbian Wheezy (Kernel 3.18.7+).

"/etc/apache2/sites-enabled/default":

Alias /webdav "/data/"
<Directory "/data/">
DAV on
Options +Indexes
AuthType Basic
AuthName DAV
AuthUserFile /pfad/zur/passwortdatei
<Limit GET HEAD OPTIONS PUT POST DELETE PROPFIND PROPPATCH MKCOL COPY MOVE LOCK UNLOCK REPORT CONNECT VERSION-CONTROL CHECKOUT CHECKIN UNCHECKOUT MKWORKSPACE UPDATE LABEL MERGE BASE
Require valid-user
</Limit>
</Directory>

Lese- und Schreibzugriff mit Cadaver funktioniert, wie gesagt, einwandfrei.

Fritzbox-Webdavclient:

webdavclient {
enabled = yes;
host_url = "http://ip-adresse/webdav";
username = "Benutzername";
password = "Passwort";
mountpoint = "Online-Speicher";
cache_files = 2000;
}

Sind das die Daten, die Du brauchst? Oder habe ich etwas vergessen?
 
Danke.
Konfiguriere...
Code:
sudo a2enmod dav_fs
sudo a2enmod dav
Code:
sudo htpasswd -c /etc/apache2/webdavpasswd Gewünschter_Username
...fertig.

Deine Konfiguration funktioniert bei mir nicht.
Ich poste mal meine funktionierende...
/etc/apache2/sites-enabled/default
Code:
alias /webdav /var/www/data/
DavLockDB /etc/apache2/DavLock
<Location /webdav>
    Order Allow,Deny
    Allow from all
    Dav On
    AuthType Basic
    AuthName DAV
    AuthUserFile /etc/apache2/webdavpasswd
    <LimitExcept GET OPTIONS>
      Require valid-user
    </LimitExcept>
</Location>
...und ich kopiere grad: Conan_der_Barbar.avi (Neue Fassung ohne Arnold)

Weil ich aber mal 1&1 Onlinespeicher aktiv hatte, musste ich noch folgendes machen...

rm -r /var/media/ftp/SanDisk-Cruzer-01/FRITZ/webdav
mkdir /var/media/ftp/SanDisk-Cruzer-01/FRITZ/webdav
mkdir /var/media/ftp/SanDisk-Cruzer-01/FRITZ/webdav/cache

...das Logfile lieferte dann...
/tmp/webdav.log
Code:
Mar 27 21:50:16 webdavclt[14050]: arg = reconfig
Mar 27 21:50:16 webdavclt[14050]: 1 - http://openelec/webdav/ - Onlinespeicher
Mar 27 21:50:16 webdavclt[14050]: stop_webdav
Mar 27 21:50:16 webdavclt[14050]: start_connection
Mar 27 21:50:16 webdavclt[14050]: stop_webdav
Mar 27 21:50:16 webdavclt[14050]: testing dir: /var/media/ftp/FRITZ
Mar 27 21:50:16 webdavclt[14050]: found not-usb-directory: /var/media/ftp/FRITZ
Mar 27 21:50:16 webdavclt[14050]: testing dir: /var/media/ftp/SanDisk-Cruzer-01
Mar 27 21:50:16 webdavclt[14050]: CACHE_DIR: /var/media/ftp/SanDisk-Cruzer-01/FRITZ/webdav/cache
Mar 27 21:50:17 webdavclt[14050]: DEV_ID: -2- DEV_SPEED: -480-
Mar 27 21:50:17 webdavclt[14050]: notify_progs
Mar 27 21:50:18 webdavclt[14050]: starting webdav client
Mar 27 21:50:18 webdavclt[14050]: mount.davfs ok

EDIT: Konfig nochmal aktualisiert, frei nach dieser Quelle
Denn für die Fritz!Box scheint diese DavLockDB /etc/apache2/DavLock wichtig zu sein.
Sonst kopiert die F!B Amok und füllt das /webdav mit 470Mb Dateileichen bis Laufwerk voll.

EDIT2: HTTPS/SSL Aktivierung geht auch relativ einfach mit dieser Anleitung.
 
Zuletzt bearbeitet:
Danke. War zwischenzeitlich mit anderen Dingen beschäftigt, daher die verspätete Antwort ...

Habe Deine Konfiguration übernommen, hilft aber leider nicht, Fehlermeldung bleibt beim Upload dieselbe ("Nicht genügend freier Speicherplatz auf dem Ziellaufwerk"). Habe auch die DavLock noch einmal überprüft (liegt bei mir unter /var/lock/apache2/), Schreibrechte stimmen (www-data), die Datei wird auch genutzt, wenn ich mit einem anderen DAV-Client auf den Speicher zugreife und schreibe.

Daran, dass mein Verzeichnis ("data") außerhalb des DeocumentRoot ("/var/www") liegt es nicht, habe das überprüft. Der Fehler bleibt derselbe, wenn ich ein Verzeichnis im DocumentRoot nehme.
 
Zuletzt bearbeitet:
Das klingt mehr nach einem Problem bei der korrekten Interpretation von Angaben zu Speichergrößen, wie es an den "magischen Grenzen" der Dateisysteme schon desöfteren aufgetreten ist. Vielleicht schaust Du mal mit einem Packetdump in die (unverschlüsselte) HTTP-Kommunikation des WebDAV-Clients (notfalls vorübergehend auf Zugriff ohne TLS umstellen, da Du in einer HTTPS-Verbindung nichts sehen kannst) und nimmst die dort übertragenen Größenangaben nebst Taschenrechner(-App :)) zur Hand. Wenn sich dann aus der Differenz der Größenangabe seitens des Servers und der FRITZ!Box ein glattes Vielfaches von 2 ergibt, wäre das ein weiteres Indiz für die Vermutung mit dem Überlauf, den Du in den Griff kriegen könntest, wenn Du einfach die Größe des DAV-"Laufwerks" entsprechend verringerst.

Du könntest natürlich auch auf dem Server hingehen und den freien Platz auf dem für DAV freigegebenen Verzeichnis systematisch so weit verringern (durch Größenänderung oder Belegung), bis die Angabe in der FRITZ!Box wieder stimmt, dann findest Du zumindest die "Barriere", an der das umschlägt. Allerdings ist dieser Weg von deutlich mehr Unwägbarkeiten gepflastert.

Wenn im DAV-Protokoll nur der gesamte verfügbare und der aktuell benutzte Speicherplatz kommuniziert wird (ich weiß es im Moment nicht genau und nachsehen kannst Du ja auch alleine), dann liegt das Problem ja vermutlich ausschließlich in der FRITZ!Box-Firmware und resultiert irgendwo aus der Differenzbildung dieser beiden Werte. Dann wird ein solcher Test sicherlich sehr aufwendig, da meiner Meinung nach für zuverlässige Ergebnisse nicht nur eine Änderung auf dem DAV-Server erforderlich ist. Um den Neustart des davfs2-Clients der Box wirst Du dann bei jeder Änderung auch nicht herumkommen und das erfordert entweder Telnet-Zugang oder mindestens das Deaktivieren und anschließende Aktivieren von "NAS aktiv" im GUI. Das ufert schnell aus, deshalb würde ich da auch mit einer "binären Suche" arbeiten (also den zu untersuchenden Bereich immer in genau zwei Hälften teilen und das solange wiederholen, bis keine Teilung mehr möglich/nötig ist) - wobei ich das ohnehin eher nicht machen würde, mir wäre die Analyse der DAV-Kommunikation und das manuelle Rechnen sympathischer.
 
Merci (@PeterPawn).

Ich muss gestehen, dass ich nicht weiß, ob ich das alles richtig verstehe und so umsetzen kann. Mit Packetdump habe ich keine Erfahrungen. Und das beste Ergebnis wäre, wenn ich Dich richtig verstehe, dass ich nur einen Teil der verfügbaren Speichers nutzen könnte. Mittlerweile frage ich mich, ob es nicht der bessere Weg wäre, das fragliche Laufwerk einfach direkt an die Fritzbox anzuschließen und auf dem Server dann einfach per Cifs einzubinden ...

Trotzdem Dank Euch beiden.

LG
 
Moin

Da ist was dran.
Für Kopieraktionen aufs WEBDAV wird immer der USB-Speicher an der Fritz!Box als Cache benötigt.
Der muss dann auch immer mindestens soviel freien Speicher bereitstellen wie für die Kopieraktion benötigt.
Dann Indiziert die Fritz!Box auch noch wie blöde...
raspberry_apache2_webdav_01.jpg
...bei mir hängen dann gerne einige luacgi_notimeout Prozesse und verbraten ne Menge CPU (20-25%).
luacgi_notimeout_raspberry_apache2_webdav_01.jpg
..erst nach manuellen killall luacgi_notimeout in eriner Konsole gings weiter.

EDIT: Dieser Prozess macht den Upload: /cgi-bin/nasupload_notimeout

Der direkte Weg wäre hierbei, zumindest im LAN/WLAN anzuraten.

Daran, dass mein Verzeichnis ("data") außerhalb des DeocumentRoot ("/var/www") liegt es nicht, habe das überprüft. Der Fehler bleibt derselbe, wenn ich ein Verzeichnis im DocumentRoot nehme.
So soll es auch sein.
Der / (Root) des Webservers bei mir: /var/www
WEBDAV liegt auf selber Höhe: /var/webdav
...sind die Daten ersteinmal da ist alles Wölkchen,
nur FritzNAS zickt rum,
bietet nur zum Download an, spielt nichts ab, zeigt nur als Textdatei an...

Im Firefox direkt aufs "https://.../webdav" jedoch werden MP3s abgespielt,
ganz genauso ausgeliefert wie in /etc/mime.conf die Dateiendungen definiert wurden.

Übrigens: WEBDAV sollte nicht mit Webtypischen Dateiendungen als zu kopierende Daten benutzt werden.
Da kann es böse Überraschungen geben, besonders mit PHP, die werden ungefragt ausgeführt.
...soll heissen: Kein HTML und PHP im WebDAV Verzeichnis

Als "FTP" Ersatz für Webseitenentwicklung also nicht so toll.
 
Zuletzt bearbeitet:
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.