Datei ist nicht vorhanden / File does not exist

Seafile Server
1

Hi,

ich habe ein kleines Problem.

Wenn ich in eine Bibliothek gehe und dort auf eine PDF-Datei klicke, dann kommt. “Die Datei ist nicht vorhanden”. Gehe ich aber auf die Versionshistorie der Datei und klicke dort auf die Datei, dann wird diese angezeigt. Wähle ich “Wiederherstellen” in der Historie, dann bringt das keinen Erfolg, ein Klick auf die Datei in der Bibliothek bringt immer noch den gleichen Fehler.

Das ganze betrifft sowohl verschlüsselte, als auch unverschlüsselte Bibliotheken.

If I clcik on a pdf file in a library, an error message is shown: “File does not exist”. But if I go to the file hitory and click on the file, the file can be opened. If I choose “restore” in the history nothing happend, the file can not be opened in the library.

This happened in encrypted and not encrypted libraries.

Seafile Server CE 6.0.6 on Raspberry Pi 3 with Apache 2.4 as Reverse Proxy and Seafile as non-root-subdomain.

2

Das scheint ein Fehler bei Pfaden mit Leerzeichen zu sein (siehe: https://github.com/haiwen/seafile/issues/1747). Aber eine Lösung hab ich noch nicht gefunden.

It seems to be a problem with white spaces in path names (see: https://github.com/haiwen/seafile/issues/1747). But there is no solution at this time?

3

Als ich deinen ersten Post las, kam mir das Problem sehr bekannt vor :wink:
Das Problem ist leider sehr ärgerlich und eine Lösung habe ich bisher nicht gefunden. Das einzige was hilft, ist alle Umlaute und Leerzeichen zu entfernen bzw. zu ersetzen, was nicht wirklich eine Lösung ist.

4

Sowas hab ich mir schon gedacht. Hab heute alles auf Nginx umgebaut und nun läuft alles wie es soll. War recht einfach.

5

Ich wünschte ich könnte auch so einfach auf Ngnix umstellen, aber das geht leider nicht.
Ich würde es wirklich sehr begrüßen, wenn Seafile einen Fix/Workaround für dieses Problem liefern würde.

6

Warum sollte das nicht gehen? Apache hat bei mir als Reverse Proxy für verschiedene Sachen (Seafile und Gogs) gedient und als Webserver zum Ausliefern verschiedener Seiten.

Was kann denn Apache, was Nginx nicht kann?

7

Grundsätzlich geht das schon, aber ich hoste auf meinem Server noch mehrere andere Anwendungen, die ich dann alle umstellen müsste und das ist mir definitiv zu viel Arbeit und birgt zu viele Risiken. I helfe mir im Moment mit NextCloud - auch wenn ich damit nicht sonderlich glücklich bin, da mir u.a. das Web-Interface von Seafile deutlich besser gefällt.

8

Genau das gleiche Problem habe ich hier auch.
Apache 2.4 / SSL / Seafile 6.0.7

Dateien mit Leerzeichen oder Umlauten kann ich nicht im Webbrowser laden.
iPad und iPhone App funktionieren problemlos.

9

Ich habe inzwischenn auch auf Nginxumgestellt, da dieses Verhalten für mich nicht aktzeptabel war. Die Umstellung ging fix und nun läuft alles. Nginx hat dabei hier die Aufgaben vonApache übernommen: Reverse Proxy (Seafile, Gogits) für verschedene Dienste und Webserver für verschiedene Webseiten.

Ich habe festgestellt, dass auf dem Pi Nginx doch etwas performanter läuft als Apache und auch etwas einfacher zu konfigurieren ist. Ich werde daher wohl bei Nginx bleiben, auch wenn der Fehler in Apache behoben wird.

10

Ich finde es schade, dass die Entwickler keinen Workaround/Fix für dieses Problem anbieten. Der Fehler ist so gravierend, dass man Seafile mit Apache nicht mehr nutzen kann :disappointed_relieved:

11

Ich bin der Meinung, dass Seafile hier gar keinen Workaround anbieten kann, da es schlichtweg an Apache liegt. Zudem muss man sagen, dass nginx in jeder Hinsicht der bessere Webserver ist.

PS: Du könntest auch nginx und Apache gleichzeitig laufen lassen und über verschiedene Wege das hinbekommen. Das einfachste wäre zum Beispiel nginx mit Seafile auf einem anderen Port zu betreiben.

12

Seh ich genauso. Jeder Workaround durch Seafile könnte bei einem Update von Apache zu Fehlverhalten führen.
Das Problem muss durch die ENtwicklung von Apache gelöst werden, zumal das Problem sehr wahrscheinlich nicht nur im Zusammenspiel mit Seafile auftaucht.

Und wenn man für Seafile jetzt sowieso Nginx einsetzen muss, dann kann man auch alles mit Nginx ausliefern und muss nicht 2 verschiedene Webserver parallel laufen lassen. Oder gibt es irgendeine Webanwendung, die mit Apache läuft und mit Nginx nicht?

13

Ich habe die Problematik bereits im Ubuntu Forum gepostet und um einen Fix gebeten, aber das scheint niemanden zu interessieren, es gab keinerlei Reaktion. Für mich völlig unverständlich, da der Bug ja in der v14.04 LTS steckt, die von sehr vielen als Server Basis genutzt wird.
Ich nutze einen V-Server mit Plesk und Plesk 12.x unterstützt z.Z. Nginx nicht vollständig d.h. ich habe nicht wirklich eine Wahl, wenn ich mir die Konfiguration nicht komplett zerschießen will. Die Sache ärgert mich schon sehr.

14

Das hat aus meiner Sicht nichts mit Ubuntu zu tun. Da müssen die Apache-Entwickler ran. Aber ich glaube, da gibt es schon einen Bugreport dazu. Wenn die Ubuntu-Leute da was basteln, hsat du wieder das gleiche Problem, falls es doch mal bei Apache gefixt wird.

Aber soweit ich das gelesen habe, tritt das Problem bei Apache Versionen bis 2.4.10 auf. Mit der Apache Version 2.4.12 scheint das gefixt zu sein. Du müsstest jetzt schauen, ob du irgendwo ein PPA mit Apache 2.4.12 oder höher findest und Apache neu installieren.

15

Das hat aus meiner Sicht nichts mit Ubuntu zu tun. Da müssen die Apache-Entwickler ran.

Das hatte ich mir auch gedacht und im IRC die Apache Jungs angesprochen. Die haben aber mit den Releases von Ubuntu nichts zu tun. Der Bug wurde ja bereits gefixt nur leider gibt es es keinen Hotfix für die aktuelle Apache Version in v14.04 - hier müssen die Ubuntu Jungs ran. Mal eben die aktuelles Apache Version unter v14.04 zu installieren führt ins Abhängigkeitschaos.

16

Hi,

I might be an acceptable solution to configure Apache to listen to an different port on localhost only (it’s a relatively small modification of one configuration file) and tell nginx to send all traffic to not explicitly defined virtual hosts to Apache:

server {
        server_name _;
        listen 443 ssl default_server;
        # ...
        location / {
                 proxy_set_header X-Real-IP $remote_addr;
                 proxy_set_header X-Forwarded-For $remote_addr;
                 proxy_set_header Host $host;
                 proxy_buffering off;
                 proxy_pass http://127.0.0.1:8080;
                 proxy_redirect default;
        }
}

Best regards

Thomas

1 Like
17

@scheff thank you for your tip. In the end I did it :relaxed:

I have upgraded my Plesk 12.5.30 to Plesk 17.0.17 (Onyx). Onyx come with “full” support of Nginx, which makes it possible to run a single subdomain e.g. Seafile with Nginx. The only downside is, that I had to modify nginx.conf to make it work, which is normally fully managed by Plesk, that means that all modifications I did, will be overwritten, when I change the subdomain configuration with Plesk in any way.

I am happy that Seafile runs without any issues again.

18

Welche Version von Apache verwendet ihr? Hatte das gleiche Problem mit Apache 2.4.6.

Verwende Centos 7 und habe dort den System Apache auf Version 2.4.25 aktualisiert, was das Problem behebt.

Ich habe dazu das IUS Repo eingebunden.
https://ius.io/GettingStarted/

short english version:
if you experience problems with white space in folder names and you use apache as you webserver try to upgrade to apache 2.4.25.

19

Ich verwende seit dem Auftreten des Fehlers keinen Apache mehr. Ich bin daraufhin zu Nginx gewechselt und habe das nicht bereut. Nginx läuft fixer und ressourcenschonender auf meinem Pi. Ich werde bei Nginx bleiben, auch wenn das Problem bei Apache gefixt ist.

20

Gibt es inzwischen einen Fix für Apache? Leider kann ich unserem Admin nicht einfach sagen “stell auf Nginx” um. Für private Systeme mag das ja funktionieren, aber große Produktivsysteme - da migriert man nicht “so schnell mal” den Server.

Kann jemand eigentlich fachlich mehr zu dem Fehler sagen? Auskunft unseres Admins war nur, dass er das Problem nicht kenne und sich schwer vorstellen könne, dass das an Apache liegen soll und dort so lange ein gravierender Bug nicht gefixt würde.