RasPi3 und neue SeafileCloud: Kann keine Dateien via WebInterface synchronisieren

Hallo,
dies ist mein erster Beitrag im Forum. Ich habe vor 2 Jahren den Raspberry Pi für mich als Hobby entdeckt, auch wenn ich nicht vom Fach bin. Meine letzten größeren Programmiererfahrungen stammen aus der Schulzeit Anfang der 80er Jahre. Vielleicht bin ich deshalb blind, obwohl ich mich eingefuchst habe.

Nach viel Überzeugungsarbeit habe ich meinen Freund dazu gebracht, von Dropbox weg zu kommen, und ich wollte ihm eine eigene Seafile-Cloud auf einem Raspberry Pi 3 einrichten, wie sie bei mir seit Anfang des Jahres wunderbar läuft. Und jetzt packe ich es nicht, obwohl ich es schon 3 Mal versucht habe.

Also, ich bekomme die Cloud zum Laufen, kann aber keine Dateien via Webinterface hoch- oder runterladen. Mit dem Windows-Client geht es.
Aber über den Browser (IE, Edge, FF) eben nicht. Auch kann ich keine Einladungsmails verschicken.

Könnte das vielleicht ein Hinweis sein, dass es nicht an Seafile, sondern an Nginx liegen könnte?

Bei fehlgeschlagenen Kopierversuchen werden keine Logeinträge unter /home/seafile/logs oder auch /var/log/nginx erzeugt. Es passiert einfach nichts und nach vielen Sekunden kommt die Meldung “Datei-Upload fehlgeschlagen, Unknown error”. Diese Meldung scheint allerdings von Seafile zu kommen.

Ich habe mich wie damals streng an Jan Karres gehalten. Diese Anleitung ist von 2013, aber neuere Anleitungen scheinen sich nicht zu unterscheiden.

Es handelt sich um einen RasPi 3 (bei mir läuft ein RasPi 2) mit aktuellem Jessie.

Habt ihr eine Idee, wo und wie ich den Fehler suchen könnte?
Viele Grüße
DocAdams

Das sind leider etwas zu wenig Informationen, um dir sinnvoll helfen zu können. Die Anleitung scheint nicht mehr online zu sein oder der Link ist falsch gesetzt. Ich würde dir davon abraten so alte Anleitungen zu verwenden - insbesondere was die Konfiguration von Seafile angeht solltest du nur der offiziellen Anleitung folgen. Gerade was was den Setup von Apache/Ngnix betrifft haben sich seit 2013 einige Details geändert.
Ich vermute mal, dass die Datei-/Verzeichnis-Rechte bei dir nicht korrekt gesetzt sind. Hast du dir mal die Logs unter /var/log/ngnix angesehen ?

Hier ist eine aktuellere Anleitung für den Raspi, vielleicht hilft dir das ja weiter.

Eine häufige Ursache für dieses Problem ist dass SERVICE_URL und FILE_SERVER_ROOT nicht korrekt gesetzt sind, siehe auch die FAQ: https://manual.seafile.com/faq/setup.html

Falls das nicht hilft, poste am besten deine Seafile- und nginx-Konfigurations-Einstellungen, dann kann dir sicher schnell Jemand weiterhelfen.

Danke für eure Antworten.
@Vertex
Der Link war wohl nur kurzzeitig down, jetzt geht er wieder. Aber die aktuellere Anleitung unterscheidet sich nur in der Reihenfolge der Installationsschritte.
Selbst die alten “Fehler” sind gleich. So befinden sich ja seit etlicher Zeit alle Configs im /conf-Verzeichnis. Ist wohl beim Kopieren übersehen worden :wink:

Ich denke, es liegt an nginx oder der Kombination nginx und der 6er Version von Seafile.
Denn, wenn ich Seafile alleine installiere, also z.B. zur alleinigen Nutzen im LAN, klappt es mit Uploads via Browser.
Sobald ich nginx installiere, kann ich im LAN Seafile starten und nutzen, aber es gehen dann keine Uploud via Browser mehr.

Gelten denn die offiziellen Anleitungen auch für den RasPi?

@Simsala
So weit bin ich ja noch gar nicht. Mein Problem, dass ich via Browser nicht mehr hochladen kann, tritt ja schon im LAN auf.

Ob das was bringt, dass ich erst mal eine 5er Version installiere?

Jep, die gelten auch für den Pi. Auf dem Pi läuft eine Version von Debian, also die Kommandos für Debian aus der Anleitung nutzen. Ich habe die von dir verwendete Anleitung von Jan Karrees mit der offiziellen verglichen. Im großen und ganzen stimmt sie schon noch, allerdings haben sich die benötigten Voraussetzungen durch die Weiterentwicklung verändert, es fehlen in deiner Anleitung folgende Pakete, die du wie folgt hinzufügen kannst: sudo apt-get install libpython2.7 python-ldap python-urllib3. Vergleiche dazu: https://manual.seafile.com/deploy/using_sqlite.html

Außerdem wurde die Variable in seahub_settings.py HTTP_SERVER_ROOT in FILE_SERVER_ROOT umbenannt und wie du ja schon selbst bemerkt hast, alle Konfigurationsdateien befinden sich jetzt im Verzeichnis conf und in der nginx-Konfiguration fehlen einige Einträge, vergleiche hiermit: https://manual.seafile.com/deploy/https_with_nginx.html

Bitte poste deine ccnet.conf, die seahub_settings.py und die seahub-nginx Konfiguration, dann kann dir besser geholfen werden.

Hallo,

ich habe noch mal völlig neu begonnen und es läuft lokal in meinem LAN bestens, auch mit SSL, nginx ind fastCGI.
Am Ende zähle ich mal alle Schritte und Eingaben auf, wen´s interessiert :wink:

Was war die Ursache? Auf alle Fälle hatte ich nicht
sudo apt-get install libpython2.7 python-ldap python-urllib3
installiert. Und ich hatte vermutlich die Adressen durcheinander gebracht. Was mich gleich zur nächsten Frage bringt.

Lokal läuft es bei mir. Von Außen geht nicht, weil bei mir ja schon meine Cloud läuft und der Router einen Port nur en einen RasPi weiter leiten kann. Das verstehe ich.
Wenn ich das bei meinem Freund einrichten will, muss ich bei ihm die Portfreigaben einrichten und die Adressen im RasPi ersetzen, also hier “seafile” durch “name.no-ip.com
Ich habe an 3 Stellen die Adresse entdeckt: /conf/ccnet.conf /conf/seahub_settings.py /nginx/sites-aviable/seahub
Gibt es noch mehr Stellen und muss ich sonst noch was beachten, wenn ich die Cloud vor Ort einrichte? Mein Freund wohnt außerhalb, ich kann da nicht schnell mal nach Hause, um was zu testen…
In den Admineinstellungen kann man ja auch die beiden Adressen ändern. Ist das sinnvoll, das darüber zu machen? Aber in nginx default muss es zumindest trotzden angepasst werden.

Hier also meine Einzelschritte, die Basis stammt von Jan Karres:
Die eingerückten Zeilen beinhalten die Daten, die ich eingegeben habe.
Der Hostname des RasPi lautet “seafile” und der USB-Massendatenträger ist unter “platte” eingebunden.
Ich habe bewusst noch nicht die DynDNS eingetragen, um nicht noch weitere Fehlerquellen zu provozieren.

sudo apt-get update && sudo apt-get upgrade -y
sudo apt-get install python2.7 python-setuptools python-simplejson python-imaging sqlite3 -y
sudo apt-get install libpython2.7 python-ldap python-urllib3 -y
sudo adduser seafile --disabled-login

Verzeichnis /media/platte/seafile anlegen User: seafile:seafile

sudo su - seafile
    wget https://github.com/haiwen/seafile-rpi/releases/download/v6.0.5/seafile-server_6.0.5_stable_pi.tar.gz
    tar -xvf seafile-server_6.0.5_stable_pi.tar.gz
    rm seafile-server_6.0.5_stable_pi.tar.gz
    cd seafile-server-6.0.5
    ./setup-seafile.sh
SeafileCloud
seafile   
/media/platte/seafile
8082 (default)

/seafile.sh start
/seahub.sh start 8000
exit


sudo nano /etc/rc.local
    # Seafilestart ohne SSL
    su seafile -c '/home/seafile/seafile-server-latest/seafile.sh start && /home/seafile/seafile-server-latest/seahub.sh start 8000'
    # Start mit SSL
    #su seafile -c '/home/seafile/seafile-server-latest/seafile.sh start && /home/seafile/seafile-server-latest/seahub.sh start-fastcgi'

sudo su - seafile
nano /home/seafile/conf/ccnet.conf
    SERVICE_URL = https://seafile:8001
nano /home/seafile/conf/seahub_settings.py
    FILE_SERVER_ROOT = 'https://seafile:8001/seafhttp'
/home/seafile/seafile-server-latest/seahub.sh stop
/home/seafile/seafile-server-latest/seahub.sh start-fastcgi
exit

als pi weiter

sudo apt-get install nginx -y
sudo sed -i "s/worker_processes 4;/worker_processes 1;/g" /etc/nginx/nginx.conf
sudo sed -i "s/worker_connections 768;/worker_connections 128;/g" /etc/nginx/nginx.conf
sudo /etc/init.d/nginx start

Testseite kommt

PHP wurde NICHT installiert !!!

SSL Zertifikat installieren

sudo mkdir /etc/nginx/ssl
cd /etc/nginx/ssl
sudo openssl genrsa -out seahub.key 4096
sudo openssl req -new -sha256 -key seahub.key -out seahub.csr        
sudo openssl x509 -req -sha256 -days 6650 -in seahub.csr -signkey seahub.key -out seahub.crt

weiter mit schritt 11

sudo nano /etc/nginx/sites-available/seahub
    ...     server_name seafile;        ...

sudo ln -s /etc/nginx/sites-available/seahub /etc/nginx/sites-enabled/seahub
sudo /etc/init.d/nginx restart

sudo nano /etc/rc.local
    # Start mit SSL
    su seafile -c '/home/seafile/seafile-server-latest/seafile.sh start && /home/seafile/seafile-server-latest/seahub.sh start-fastcgi'

zur Sicherheit

sudo reboot

Die Cloud lässt sich korrekt mit https://seafile:8001 aufrufen und nutzen.

Die drei Stellen sind korrekt.

Das ist Geschmackssache, wichtig ist nur: wenn du es einmal mit dem Webinterface verändert hast, dann wird nur noch dieser Wert verwendet, nicht mehr der in der Konfig-Datei! Das liegt daran, dass das Webinterface nicht die Konfigdatei verändert, sondern die Einstellung in die Datenbank schreibt und dieser Wert bevorzug behandelt wird.

Grundsätzlich sieht dein Aufbau gut aus, habe allerdings drei Anmerkungen dazu:

  1. Mir ist nicht klar, wieso Jan Karres Seafile unter dem Port 8001 laufen lässt, finde das recht unpraktisch. Schöner wäre Port 443, das ist der Standardport für SSL-Verbindungen. Der Link würde dann also statt https://deinedyndns.de:8001 nur noch https://deinedyndns.de heißen (der Standardport kann immer weggelassen werden. (Nebeneffekt: so könntest du auch in deinem Netzwerk beide PI’s betreiben und mit DynDNS testen)
    Die Variablen wären dann:
  • FILE_SERVER_ROOT = 'https://deinedyndns.de/seafhttp'
  • SERVICE_URL = https://deinedyndns.de
  • und in nginx listen 443; anstatt listen 8001;
  1. Ganz schick wird es noch mit einem letsencrypt-Zertifikat, dann kommt keine Zertifikats-Warnung mehr :wink:
  2. Seafile über die /etc/rc.local zu starten ist eher ein quick’n dirty workaround, und kann unter Umständen dazu führen, dass Seafile nach dem booten des PI’s nicht startet. Schöner ist es mit einem Start- und Stopscript: https://manual.seafile.com/deploy/start_seafile_at_system_bootup.html
    Für Debian prüft dieses ob eine Netzwerk-Verbindung besteht, das Filesystem (zB bei externer Festplatte) schon eingebunden wurde usw. und startet erst dann Seafile.

Ich bin stolz auf mich :wink: na gut, kann halt abtippen…

Danke für das Start/Stop-Script, ich habe die Debian-Variante genommen. Allerdings verstehe ich nicht, warum noch mal ein Log-Verzeichnis erstellt werden soll. Das gibt es doch schon…

Das letsencrypt-Zertifikat werde ich demnächst bei mir einrichten. Danke für den Tipp. Aber nur 90 Tage Gültigkeit ist sicher sicher, aber oft unpraktikabel.

Den Port 8001 hat er sicher genommen, um halt nicht “das Übliche” zu nehmen. Er schlägt ja auch vor, den user pi umzunennen, um Fremde noch mehr zu verwirren, falls sie sich doch auf den Pi verirrt haben. Ob das sinnvoll ist, kann ich nicht beurteilen, da habe ich viel zu wenig Hintergrundwissen. Der Port 8000 bzw. 8001 ist mir auch schon bei anderen Tutorials begegnet.

Danke für den Hinweis, ich werde auch künftig alle Anpassungen in den conf-Dateien vornehmen.

EDIT: Wie kann das gehen, dass ich 2 Server im LAN betreiben kann, die mittels DynDNS von außen erreichbar sind? In meiner Fritzbox kann ich nur einen DynDNS-Anbieter eingeben.

Du kannst es dir so einrichten, dass es vollautomatisch erneuert wird.

EDIT: Wie kann das gehen, dass ich 2 Server im LAN betreiben kann, die mittels DynDNS von außen erreichbar sind? In meiner Fritzbox kann ich nur einen DynDNS-Anbieter eingeben.

Das geht nur per port forwarding beide sind dann natürlich nur über eine Adresse/Domain erreichbar unter unterschiedlichen Ports.
Gggfs. solltest du dir vielleicht überlegen dir einen Virutal Server anzuschaffen, gibt es für vergleichsweise kleines Geld. Du sparst die Stromkosten, brauchst kein DynDNS und bekommst auch gleich einen eigenen Mail-Server etc. :slight_smile:

Ich verwende auch letsencrypt und das erneuern ist sehr einfach. Ausserdem bekommt man Erinnerungsmails wann die Zertifikate ablaufen.

Das Problem hatte ich auch. Habe nach außen nur den HTTPS Port 443 freigegeben. Dieser wird auf meinen Seafile-Server weitergeleitet. Erreichbar ist er dann unter https://seafile.domain.de. Um einen weiteren Server im gleichen Netzwerk von außen zu erreich, einfach mit NGINX einen proxy_pass auf den zweiten Rechner schalten. Zum Beispiel für die Adresse https://seafile2.domain.de

@DocAdams: Freut mich dass du die Vorschläge direkt umgesetzt hast!

Sorry, da habe ich mich nicht klar genug ausgedrückt: Wenn die beiden Seafile-Server auf unterschiedlichen Portnummern laufen, ist dies eine Möglichkeit beide über eine DynDNS anzusprechen, da du dann zwei Forwarding-Regeln in deinem Router einstellen kannst. Dies st eine Möglichkeit um “mal eben” zu testen ob der Server von außen korrekt funktioniert.
Für einen dauerhaften parallelen Einsatz ist @Jack’s Vorschlag über einen proxy_pass eleganter.

Kleiner Zwischenstand von mir.
Ich habe den Port auf 443 umgerüstet, wobei das Anhängen von “:8001” auch nicht die Hürde wäre.
Das Start-/Stop-Script läuft inzwischen auch, nachdem ich zunächst etwas missverstanden und falsch angepasst hatte. Naja, ich komme nicht vom Fach, aber man lernt ja nie aus.
Hier zumindest läuft der neue Server jetzt Dank eurer Hilfe top, nächste Woche wird sich zeigen, ob es bei meinem Freund auch läuft.
Mit letsencrypt werde ich mich später und erst mal bei meinem Server beschäftigen. Es schein ja verschiedene Meinungen zu geben, vor allem zu dem Automatismus. Aber die größere Hürde scheint zu sein, dass ich ja über einen DydDNS-Dienst zur Cloud komme. Und wenn ich da in der Woche zu spät ein neues Zertifikat erzeugen will, habe ich Pech… Und bei einem Automatismus noch mehr Pech, weil ich das zunächst einmal nicht mitbekomme. Zu den Zertifikaten habe ich ohnehin noch Fragen, das wird aber ein neues Thema.

Was noch ungelöst ist, ist die Möglichkeit, 2 Server gleichzeitig zu betreiben. Das ist ja nun ein temporäres Problem und wird wahrscheinlich danach nie wieder bestehen. Darum ist für mich nur die Variante mit den verschiedenen Portweiterleitungen interessant. Aber die Umsetzung habe ich nicht verstanden.

Derzeit ist das bei meiner FritzBox so eingerichtet (Beispielhaft für diesen Port):
Protokoll: TCP
von/bis Port: 8082
an: Seafile-RasPi
an Port: 8082

Laut Wikipedia ist z.B. der Port 1988 standardmäßig unbelegt und ich habe den auch nicht in Gebrauch.
Wie sieht nun für den zweiten Webserver die Portweiterleitung aus?
Protokoll: TCP
von/bis Port: 1988
an: Seafile-RasPi-2
an Port: 8082
Oder muss ich da bei der Konfiguration des zweiten Webservers überall Port 8082 zu Port 1988 ändern und es geht dann in der FB von Port 1988 an Port 1988?

In der FB habe ich einen DynDNS einberichtet und meine Cloud rufe ich von Außen so auf: https://name.dyndns.eu Bei meinem Freund habe ich einen anderen Domainnamen eingerichtet und wir werden ihn dort mit https://name2.dyndns.eu aufrufen. Aber wie mache ich das jetzt hier bei mir?

Ich finde es super dass du dich nicht von neuen Ideen abschrecken lässt und es einfach ausprobierst, genau so lernt man es!

Ja genau, diesen Weg würde ich gehen, dann sollte es auch keine Up- oder Downloadprobleme geben.

Hm, muss ich nicht noch in der Fritzbox die zweite DynDNS Adresse bekannt geben?
Sonst wüsste doch der DynDNS-Anbieter gar nicht, an welche momentane IP die Anfragen geschickt werden sollen. Oder liege ich da völlig daneben?

Welche Ports müssen alles geändert werden? 8080 8082 10001 12001 , 443 bleibt vermutlich ?
Kann ich als Ersatz jeden beliebigen Port nehmen, der in Wikipedia nicht aufgelistet ist?
Aber ich sehe z.B. Port 10001 wird im Projekt verwendet (lt. Jan Karres muss eine Portweiterleitung eingerichtet werden), aber dieser Port wird inoffiziell von “Lantronix UDS-10/UDS100[64] RS-485 to Ethernet Converter Voreinstellung” verwendet…

In der Fritz.box kannst du nur eine DynDNS-Adresse eintragen, aber das reicht ja auch:

Die Info in der Anleitung von Jan ist leider auch schon überholt. Die Ports 8082, 10001 und 12001 müssen NICHT mehr geöffnet werden, es reicht den Port zu öffnen der hinter der Domain steht. Dies wäre in deinem Fall dann also nur Port 443 bzw. für den zweiten Seafile-Server den von dir gewählten (zB 8080).

So, nun laufen auch beide Server gleichzeitig bei mir. Ich hatte es mir mal wieder komplizierter vorgestellt, als es am Ende ist. Vielen Dank für eure ausführliche und geduldige Hilfe.

Zwei Probleme beschäftigen mich noch in diesem Zusammenhang, die aber nicht unmittelbar mit dem Ausgangsproblem zu tun haben.

Mir ist aufgefallen, dass die Standard-HTML von Nginx noch unter HTTP://… von aussen sichtbar ist. Alle Versuche, HTTPS://… zu erzwingen, scheitern an meiner Unkenntnis. Die Tutorials, die ich dazu gefunden habe, sind allerdings auch nicht speziell für Seafile geschrieben.
Muss ich da etwas bei der nginx.conf bzw. /sites-availabele/default bzw. /sites-availabele/seahub beachten? Ihr seht, ich stochere im Nebel.
Also, falls ich mich zu kompliziert ausgedrückt habe, ich möchte, dass jemand, der http://name.dyndns.de eingibt, ohne Weiteres automatisch auf https://name.dyndns.de landet.

Das Zweite ist eher theoretischer Natur.
Wie schon erwähnt, betreibe ich den Server nur privat für Familie und Freunde. Ich werde also die Adresse kaum in die Welt tragen. Fremde werden also nur durch Zufall an die Adresse kommen und sie zu knacken versuchen. Ich habe mir mal auf dem Handy Fing installiert und die beiden Server von außen scannen lassen. Während mein Server (also der mit Port 443) zumindest mit dem Service 5060 SIP sichtbar ist, ist der andere Server (also der mit Port 8xxx) überhaupt nicht erreichbar. Auch wenn ich explizit nach der Adresse samt Port scanne. Also ist doch ein “exotischer” Port noch eine Nummer sicherer, oder?

Das kannst du mit einem extra Server-block in deiner seafile-nginx-konfig erreichen:

server   {
    listen 80;
    server_name name.dyndns.de;
    return 301 https://$server_name$request_uri;
 }

Damit das etwas bringt, musst du allerdings auch eine Portweiterleitung für Port 80 auf den Server einstellen. Alternativ kannst du den Port einfach geschlossen lassen, dann würde allerdings beim Zugriff ohne SSL eine Fehlermeldung erscheinen dass der Server nicht erreichbar ist.

Zur zweiten Frage:
Der Port 5060 ist der VoIP-Port der Fritzbox, hat also mit dem ersten Server nichts zu tun.
Um den Schutz deines Servers vor Fremden, die per Zufall die richtige IP herausfinden zu erhöhen, kannst du noch folgenden weiteren Serverblock hinzufügen:

server {
    listen     80 default_server;
    server_name _;
    return      444;
   server_tokens off; ## Don't show the nginx version number, a security best practice
}

Dies gibt einen Fehler 444 zurück, wenn die Seite ohne Domainname (also zB nur über die IP-Adresse) aufgerufen wurde.

Einen weiteren Schutz vor Zugriffsversuchen könntest du noch mit fail2ban erreichen. Dies sperrt IP-Adressen für eine vorgegebene Zeit, wenn von diesen mehrere fehlgeschlagene Login-Versuche registriert wurden.

Ob ein exotischer Port wirklich sicherer ist, kann ich leider nicht beantworten. Vielleicht liest ja ein Sicherheitsexperte mit und kann hierzu etwas sagen? Ich kann mir aber schon vorstellen dass Ports die für keinen bestimmten Dienst reserviert sind, seltener durchforstet werden.

Den ersten Server-Block hatte ich auch schon probiert, allerdings den Hinweis auf die Portweiterleitung für Port 80 nicht gemacht/gewusst. Jetzt klappt es. Vielen Dank.

Wenn ich den zweiten Serverblock in die seafile-nginx-konfig speichere, bin ich überhaupt nicht mehr erreichbar. Ich habe es erst mal wieder auskommentiert. Die …/sites-availabele/seahub sieht jetzt so aus:

# siehe https://forum.seafile.com/t/raspi3-und-neue-seafilecloud-kann-keine-dateien-via-webinterface-synchro$
server   {
    listen 80;
    server_name name.dyndns.de;
    return 301 https://$server_name$request_uri;
 }

#server {
#    listen     80;
#    listen     443;
#    server_name "";
#    return      444;
#   server_tokens off;  ## Don't show the nginx version number, a security best practice
#                       ## wenn einer zufällig nur die IP trifft, kommt eine unspezifische Fehlermeldung
#}

server {
    listen 443;
    ssl on;
    ssl_certificate /etc/nginx/ssl/seahub.crt;
    ssl_certificate_key /etc/nginx/ssl/seahub.key;
    server_name name.dyndns.de;
    if ($scheme = http) {
        return 301 https://$server_name$request_uri;
    }
    error_page 497  https://$host:$server_port$request_uri;
    client_max_body_size 50G; # set max upload size
    location / {
        fastcgi_pass    127.0.0.1:8000;
        fastcgi_param   SCRIPT_FILENAME     $document_root$fastcgi_script_name;

Die Reihenfolge der Blöcke ist doch egal?

Sorry dafür, so funktioniert es tatsächlich nicht. Versuch es mal hiermit:

server {
    listen      80 default_server;
    server_name _;
    return      444;
   server_tokens off; ## Don't show the nginx version number, a security best practice
}

Dies sollte für HTTP-Anfragen funktionieren, wie es für HTTPS-Anfragen geht weiß ich leider nicht. Hat hier Jemand einen Tipp?

Das sollte überflüssig sein, da es in dem SSL/TLS-Block steht. Hier wurde ja schon eine HTTPS-Verbindung aufgebaut.

1 Like

Nein, genau umgedreht, bei https://123.234.345.456 kann er “leider nicht auf die Seite zugreifen” und bei http://123.234.345.456 zeigt er die Index.html. Eventuell spielt da die default-Datei im gleichen Verzeichnis mit rein.

Aber ich glaube, wir entfernen uns zu sehr vom ursprünglichen Problem, das ja inzwischen mehr als gut gelöst wurde. Ich habe jetzt eine blanco-index.html ohne jeglichen Informationsgehalt erstellt. Das muss reichen.

Dank deiner Hilfe habe ich auch meine Cloud noch deutlich sicherer gemacht, als sie vorher war. Glaube ich jedenfalls :wink:
Und dafür möchte ich mich nochmals ganz herzlich bedanken.

1 Like