Entries tagged as Seafile

Seafile: Bad URL in Request

In Post Seafile: Upgrade von 6.1.2 auf 6.2.2 fehlgeschlagen erwähnte ich am Schluss, dass ich nach dem Upgrade beim Zugriff auf das UI per Browser die Meldung: "Bad URL in Request", erhalte. Für diejenigen, die auch diesen Fehler erhalten, möchte ich an dieser Stelle noch die Lösung nachreichen, die - zumindest in meinem Fall - für Abhilfe schaffte:

Ich editierte meine NGinx Konfiguration, indem ich die Zeile

proxy_set_header Host $host;

durch

proxy_set_header Host $host:$server_port;

ersetzte.

Nach dem Speichern blieb die Fehlermeldung weg und ich war wieder im UI.

Seafile: Upgrade von 6.1.2 auf 6.2.2 fehlgeschlagen

Das Upgrade des Seafile Servers von 6.1.x auf 6.2.2 auf meinem Raspberry Pi schlug erwartungsgemäß fehl. Wie in den Anmerkungen zum Paket angegeben, nahm ich die Anpassungen in Nginx (sudo nano /etc/nginx/sites-available/seahub) vor, scheiterte dann aber beim Upgrade Befehl: upgrade_6.1_6.2.sh . Ich erhielt dabei immer nur folgende Fehlermeldung:

QUOTE:

Updating seafile/seahub database ...

[INFO] You are using SQLite3
[INFO] updating seahub database...
Traceback (most recent call last):
File "/home/.../seafile/seafile-server-6.2.1/upgrade/db_update_helper.py", line 363, in
main()
File "/home.../seafile/seafile-server-6.2.1/upgrade/db_update_helper.py", line 358, in main
db_updater.update_db()
File "/home/.../seafile/seafile-server-6.2.1/upgrade/db_update_helper.py", line 259, in update_db
super(SQLiteDBUpdater, self).update_db()
File "/home/.../seafile/seafile-server-6.2.1/upgrade/db_update_helper.py", line 120, in update_db
self.update_seahub_sql(seahub_sql)
File "/home/.../seafile/seafile-server-6.2.1/upgrade/db_update_helper.py", line 283, in update_seahub_sql
self.apply_sqls(self.seahub_db, sql_path)
File "/home/.../seafile/seafile-server-6.2.1/upgrade/db_update_helper.py", line 273, in apply_sqls
conn.execute(line)
sqlite3.OperationalError: no such table: sysadmin_extra_userloginlog

Failed to upgrade your database


Na, toll.
Also frickelte ich mir einen zurecht und passte erst die "seahub.sql" im Upgrade Verzeichnis des Pakets unter sql/6.2.0/sqlite3/ an, indem ich folgende Zeilen hinzufügte:

QUOTE:

CREATE TABLE "sysadmin_extra_userloginlog" ("id" integer NOT NULL PRIMARY KEY AUTOINCREMENT, "username" varchar(255) NOT NULL, "login_date" datetime NOT NULL, "login_ip" varchar(128) NOT NULL);
CREATE INDEX "sysadmin_extra_userloginlog_14c4b06b" ON "sysadmin_extra_userloginlog" ("username");
CREATE INDEX "sysadmin_extra_userloginlog_28ed1ef0" ON "sysadmin_extra_userloginlog" ("login_date");


Ich speicherte die Änderungen und startete das Upgrade per sudo ./upgrade_6.1_6.2.sh erneut. Doch wieder erhielt ich die Fehlermeldung. Also machte ich mich daran, die drei Zeilen direkt in die Datenbank zu schreiben und dabei unterlief mir ein Denkfehler, denn ich bearbeitete die seahub.db im sqlite3 Verzeichnis des Upgrade Ordners. Ich erhielt erneut dieselbe Fehlermeldung, bis ich drauf kam! Die relevante und zu bearbeitende Datenbank liegt natürlich im Seafile Verzeichnis und muss, da schreibgeschützt, mit erweiterten Rechten bearbeitet werden.

Also zurück nach /home/seafile, zu root gewechselt und per nano seahub.db die Datenbank um obige drei Zeilen ergänzt. Das ganze dann gespeichert, von root wieder zum Pi User zurükgewechselt und das Upgrade ausgeführt, das nun endlich erfolgreich durchlief.

Abschließend startete ich seafile.sh und seahub.sh wieder, wobei der Start von seahub.sh nach den Änderungen in Nginx jetzt nicht mehr per ./seahub.sh start-fastcgi erfolgte, sondern nur noch per ./seahub.sh start.

Mein Client war danach auch direkt wieder verbunden, aber das Web Interface bringt mir noch eine "Bad URL in request" Meldung. Diesen Fehler muss ich jetzt im zweiten Schritt beheben. Doch soweit so gut schonmal.


Seafile: Dateien werden von einer anderen Anwendung verwendet

Der Seafile Desktop Client weigert sich, einen Ordner zu synchronisieren und stellt dies mit einem "!" dar sowie dem Hinweis, dass die Dateien von einer anderen Anwendung verwendet werden würden.
Hier könnte man meinen, dass es etwas mit der File Lock Funktion haben könnte und die Synchronisation fehlschlägt, weil Dateien offenbar gesperrt oder noch geöffnet sind. Doch es handelt sich scheinbar viel mehr um einen Fehler, der sich leicht beheben lässt, indem man die Synchronisation des betroffenen Ordners aufhebt und dann erneut (mit einem bestehenden Ordner) einrichtet.

HTTPS für Seafile mit Nginx

Lang, lang ist's her, dass ich meinen letzten Eintrag hier tätigte, aber zum Jahresende gab's so einiges zu tun und ich hatte keine Zeit und Muße zu schreiben. Jetzt aber ist alles wieder ein wenig ruhiger und ich nutze gerade die Zeit, da ich mir 'ne dicke Erkältung eingefangen habe, meinen Seafile-Server auf HTTPS umzustellen. Anleitungen gibt's dazu so einige wie z.B. unter:

http://jankarres.de/2013/06/raspberry-pi-owncloud-alternative-seafile-server-installieren/
oder direkt bei Seafile: http://manual.seafile.com/deploy/deploy_with_nginx.html

Die Anleitung von Jan Karres zur Installation und Einrichtung von Nginx und die Anpassung von Seafile ist gut erklärt und führt i.d.R. zum Ziel. Bei mir jedoch hakte die Umstellung ein wenig, da ich den Standardport für Seafile bei mir durch einen anderen ersetzt hatte und so machte ich bei der Umstellung einen Denkfehler und wunderte mich, weshalb das Rewrite von http:// auf https:// nicht klappte und weshalb die Seite partout nicht erreichbar war (502 Bad Gateway seitens Nginx).

Ok, eine zusätzliche Portfreigabe für den neuen Port für https:// hatte ich im Router bereits eingerichtet, doch ich kam bei der Konfiguration von Nginx und dem Starten von Seahub via "fastcgi" durcheinander.
Aber nach einer kleinen Denkpause kam ich auf den Trichter und löste das ganze schließlich so:

Seafile:

QUOTE:
SERVICE_URL in der ccnet.conf lautet nun: https://meinserver:4001 (Port von 4000 http auf 4001 für https geändert)
FILE_SERVER_ROOT in der seahub_settings.py lautet nun: https://meinserver:4001 (Port von 4000 http auf 4001 für https geändert)


In meiner für Seafile angelegten Site für nginx ("seahub") lauten die Einträge nun:

QUOTE:
server {
listen 4000;
server_name meinserver;
rewrite ^/(.*)$ https://$host:4001/$1; # Port mit angegeben, da die Weiterleitung sonst nicht klappt
}

server {
listen 4001;
ssl on;
[...]
fastcgi_pass 127.0.0.1:8000;
[...]
}


Danach startete ich Seahub per ./seahub.sh start-fastcgi und startete den Nginx-Dienst per "sudo service nginx start" neu.
Jetzt ist die Seite via https://meinserver:4001 zu erreichen sowie bisher über http://meinserver:4000, wobei bei letzterer Adresse eine Weiterleitung erfolgt.

Im Client änderte ich die Adresse noch ab und deaktivierte die Zertifikatsprüfung und komme jetzt wieder ins Webinterface und der Client verbindet sich sauber.


Weshalb das Starten von Seahub oder Nginx davor immer fehlschlug, lag daran, dass ich Seahub per "./seahub.sh start-fastcgi 4001" starten wollte und Nginx beim Starten dann meckerte: ""bind() to 0.0.0.0:4001 failed (98: Address already in use)".
Startete ich zuerst den Nginx Dienst und dann Seahub per "./seahub.sh start-fastcgi 4001", wollte Seahub nicht mehr starten.
Die Lösung ist dabei so einfach, wie für mich anfänglich aber nicht klar: In der Nginx Site muss (!) der fastcgi Wert "fastcgi_pass" auf 127.0.0.1:8000 stehen und Seahub muss per: "./seahub.sh start-fastcgi" ohne weitere Portangabe gestartet werden. Danach läuft Nginx sauber, hört auf die angegebenen Ports und leitet Anfragen entsprechend weiter.
Ich hatte mich schlichtweg zu sehr am Port 8000 gestört, den ich partout nicht haben wollte, weil ich ja bewusst einen anderen ausgewählt hatte.

Seafile: Upload und Löschen nicht möglich

Seafile macht - leider - mal wieder Probleme. Über die Smartphone-App lud ich die Tage ein paar Fotos in eine Bibliothek und legte in selbiger heute abend per Rechner noch einen Ordner an, in den ich weitere Dateien schob. Während der Upload via PC-Client in andere Bibliotheken problemlos funktioniert, erscheint hinter dem einen Ordner ein "!". Die Löschungen, die ich clientseitig vornahm, wurden dabei nicht übertragen und auch der Upload weiterer Dateien scheitert. Im Webinterface sind die zu löschenden Dateien immer noch da und lassen sich leider nicht wegbekommen. Die lapidare Fehlermeldung: "Interner Fehler: Datei *******.jpg konnte nicht gelöscht werden". Auch das Speichern von Einstellungen für diese Bibliothek sowie für weitere scheitert mit dem Fehler: "Speichern der Einstellungen auf dem Server fehlgeschlagen".

So, was genau ist jetzt das Problem ? Speichermangel mal wieder ? Also sah ich mir via "tail seafile.log" das Logfile mal an und siehe da: "No space left on device." Also rief ich mal eben "ncdu" auf, das ich seinerzeit für solche Fälle mal auf dem RPi installierte und sah, dass "Storage" auf dem externen Datenträger den Speicherplatz komplett ausschöpfte. Und darin liegt das Verzeichnis "blocks", das immer wieder für übervolle Datenträger sorgt. Leider ist dies in Version 4.3.1 für Seafile immer noch nicht behoben, weshalb mal wieder Handarbeit angesagt war.
Unter "blocks" führte ich erneut "ncdu" aus und erhielt drei Repositories, die aus allen Nähten platzten, dies in Wirklichkeit aber gar nicht tun.

Seafile stellt zur Entrümpelung ein kleines Tool namens "GC" bereit, das sich im Seafile Serververeichnis befindet und das ich per "sudo ./seaf-gc.sh run" startete. Diesmal jedoch passiert hierbei nicht allzuviel.
Die Meldung: "Starting seafserv-gc, please wait ... [08/15/15 21:28:58] gc-core.c(454): === GC is finished === seafserv-gc run done" war das einzige, das ich zu sehen bekam, aufgeräumt wurde jedoch nichts. Und ein Integritätscheck per "sudo ./seaf-fsck.sh" brachte auch nichts. Sämtliche Repositories wurden als fehlerfrei aufgelistet. Also führte ich "sudo ./seaf-gc.sh" nochmal ohne "run" aus und schon wurde fleißig entrümpelt. Danach ein Integritätscheck und eine erneute Prüfung mit "ncdu" im "Blocks"-Verzeichnis und dann passte alles wieder.

Lästig, dass Seafile hier nicht sauber arbeitet und das trotz einer kurz eingestellten History und dem kompletten Löschen der Files.

Page 1 of 4, totaling 16 entries