Anmeldung - dauert lange - Fehlermeldung 405 Not Allowed nginx

🌐 Non-english support đŸ‡©đŸ‡Ș Deutsch (german)
1

Hallo Nextcloud User,

ich habe bei mir ein Problem, das mir unerklÀrlich ist


Ich habe mehrere Benutzer angelegt. Seit dem Update auf 21.0.1 fĂ€llt mir auf, die Anmeldung ist “gefĂŒhlt” langsamer und vor allem bei einem User, kann ich mich nicht anmelden, ich erhalte im Browser (verschiedene ausprobiert
) die Meldung:

405 Not Allowed - nginx

Ich kann aber mit diesem User z.B. via Desktop Client - die Synchro mit meinem Desktop Computer durchfĂŒhren, das klappt einwandfrei

Das seltsame, alle anderen User sind davon nicht betroffen!

Mein System:
Nextcloud lÀuft im Docker auf einer Synology NAS
Zugriff ĂŒber eine Subdomainn mit DNS CNAME auf die DynDns der NAS
Mit Reverse Proxy intern auf den Docker Port
Zertifikat von Let’sEncrypt auf der NAS eingerichtet

Wie gesagt, das System funktionierte bis zum letzten Update bestens :slight_smile:

Ich habe schon mal eine Kopie dieser Nextcloud erstelllt und dann im Docker mit direktem Zugriff via freigegebenen Port getestet - und das gleiche Verhalten


Und jetzt wird es noch mysteriöser - manchmal kann ich mich mit diesem User trotzdem am Browser anmelden


Ich habe auch schon mal auf der NAS alle möglichen Sicherheitseinstellungen temporĂ€r dekativiert
 keine Änderung - natĂŒrlich Neustart WebStation und auch Neustart NAS getestet

Sogar meinen Internet Provider habe ich mal meinen Account testen lassen, auch angeblich alles ok


Jetzt bin ich gespannt, ob jemand von Euch dazu eine Idee hat :slight_smile:

GrĂŒĂŸe
Thomas

2

Hallo @Thomas65

lass uns das mal eingrenzen.

  • Generell hast du Zugriff und die Login-Seite lĂ€dt auch problemlos → das Problem ist also nicht Domain/Portforwarding/PHP/Datenbank/Webserver
  • Mehrere Benutzer können sich problemlos anmelden (das ZeitgefĂŒhl lasse ich mal außen vor) → NC selbst lĂ€uft und ist korrekt installiert
  • Ein Nutzer kann sich nicht anmelden

Dazu wĂŒrde mir zB falsch gesetzte Ordnerrechte/BesitzverhĂ€ltnisse der Userverzeichnisse einfallen. Könntest du das mal nachschauen? Die sollten alle dem User des Webservers gehören (rekursiv).

/S

3

Hallo simonspa,

Ja, das hatte ich auch schon mal im Kopf, aber warum kann ich mich dann immer wieder mal mit diesem User einloggen


Zur Sicherheit, habe mit PuTTY reingeschaut, alle Ordnerrechte
 sind mit den anderen Usern identisch auch in den Unterverzeichnissen.

Jetzt wieder Du :slight_smile:

Gruß Thomas

4

Puh, harte Nuss
 :smiley:

  • Hat der User irgendwelche Sonderzeichen im Namen?
  • Kannst du mal deine nginx-Konfiguration mit der Version aus dem Manual abgleichen? Da gab es ein paar Änderungen.
5

Hallo,

das ist ja auch das Erstaunliche, nginx? woher kommt die Meldung, meine Synology NAS ist auf der WebStation auf Apache 2.4 konfiguriert


Noch etwas, jetzt ist noch ein Zweiter (Test)User betroffen

und eventuell mal zur Eingrenzung, mit diesen beiden Konto fĂŒhre ich auf Outlook/Smartphone CalDav Synchros durch


Outlook CalDav Synchronizer, Android Smartphone mit App OpenSync

Wie gesagt, bis vor kurzem hat alles funktioniert :slight_smile: :joy:

Never change a running system! - Nee, Spaß beiseite


6


 Sonderzeichen? Ja, der eine User das “_” zweimal, aber der andere betroffene User nicht,
der ist total simpel

7


okay, wir haben vermutlich den Punkt erreicht, wo du vielleicht doch mal deine Systemkonfiguration posten solltest. Ansonsten ist das reines Raten im Dunkeln.

8

Du meinst die config.php - mit meinen specials ausgepixelt oder was brauchst Du sonst noch?

9

Naja, du hast eben erst ein wenig ĂŒber den Setup geschrieben - ich wĂŒsste gerne welcher Webserver, welche PHP version und Datenbank, wo die Daten liegen, warum da ein nginx auftaucht wenn du nur Apache benutyt und die Sachen. Also einfach die Konfiguration deiner Installation. :slight_smile:

10

Also, jetzt hast Du mich auf die richtige Spur gebracht

NatĂŒrlich ist auf der Synology nginx installiert, und mein WebStation Einstellungen der Synology sind fĂŒr die Nextcloud uninteressant :slight_smile:
Jetzt schaue ich mir mal die nginx Konfiguration im Manual an
 (das Du mir schon verlinkt hast)

Ich melde mich

11

Also, jetzt funktionert mein “wichtiger” User wieder einwandfrei - zwar “lange” - im Vergleich zu anderen Usern - in der Anmeldezeit, aber ich kann mich wiederholt sauber anmelden und arbeiten.

Funny, jetzt funktioniert aber mein Testuser den ich neu angelegt hatte mit den gleichen Symptomen wie vorher der wichtige User nicht mehr!!!

Ich habe jetzt wirklich einiges ausprobiert, von Apache auf nginx umgestellt, Reverse Proxy nochmal neu angelegt, Passwort des Testusers neu vergeben
 usw.
Jetzt habe ich keine Lust mehr, obwohl mir das sehr zu denken gibt


Ich kann einfach keine Logik finden 


Trotzdem Vielen Dank!!

12

nur eins wollte ich zu dem Thema noch nachreichen, in der audit.log wird der User als “login sucessful” geloggt, obwohl im Browser (verschiedene Google, Firefox, Edge und verschiedene IP-Kreise Home und Office , also auch Computer) den error “405 not allowed - nginx” auswirft


13

Die eigentliche Authentifizierung scheint zu funktionieren - das macht aber auch nicht nginx sondern NC in PHP. Deinem Browser-Log oben kann man entnehmen, dass das “not allowed” direkt von nginx kommt (eine fehlerhafte Anmeldung bei NC sieht anders aus) und sich nur auf statische Dateien wie Stylesheets bezieht. Das sieht also wirklich nach einem vorgelagerten Problem aus und keinem mit NC selbst.

14

Hi simonspa,

ich habe jetzt folgendes durchgefĂŒhrt, ich hatte meinem Testuser und auch meinem wichtigen User relativ einfache Passwörter zum Test vergeben. Heute morgen wollte plötzlich mein wichtiger User auch nicht mehr :frowning:

Aber, dann habe ich wieder gute Passwörter (Zufallsgenerator 20 Zeichen) vergeben und

  • alles funkt wieder super!!!

Bin ich ein 


Sei’s drum - Schönen Tag!

Gruß Thomas

15

Hallo Thomas,

ich habe gerade das selbe Problem. Wie du auf einem Synology NAS. Nextcloud in einem Docker Container und Zugriff ĂŒber den Synology Reverse Proxy mit HTTPS auf HTTP.

Leider brachte das Passwort hin und her Ă€ndern bei mir keine Besserung. Wenn ich allerdings den Reverse Proxy rausnehme und direkt ĂŒber HTTP auf den Docker Container gehe kann ich mich anmelden.

Was kann an einem Reverse Proxy “falsch” eingestellt sein, dass ich mich mit einem User anmelden kann, mir dem anderen aber nicht???

Vielen Dank fĂŒr die Hilfe!

Gruß Blackmore

16

Hallo Blackmore,

einerseits ist es gut, dass ich nicht der Einzige bin, der dieses Problem hatte bzw. immer noch sporadisch hat. Jedoch kaum nennenswert oft.

Aber nun, was habe ich gemacht. Wie schon im Verlauf beschrieben habe ich die Passwörter geĂ€ndert, aber das alleine kann es nicht gewesen sein


Die Umstellung den Reverse Proxy rauszunehmen, habe ich auch gemacht. Ich bin mir jetzt nicht 100% sicher ob es dann richtig funktioniert hat, ich habe wirklich so einiges ausprobiert


Ich habe auch alles wieder so wie es richtig ist, eingestellt. Reverse Proxy und HTTPS auf HTTP und den internen Port.

Wo meiner Meinung nach etwas schieflÀuft sind die Sicherheitseinstellungen der Synology.

Ich habe temporÀr mal die Einstellungen unter Sicherheit deaktiviert:
-Schutz gegen Cross-Site-Request

-Sicherheit mit HTTP Content Security

unter “Schutz”
-DoS Schutz aktivieren
unter “Erweitert”
-Schutz gegen Spectre und Meltdown (Neustart der NAS nötig)

deaktiviert, und dann wieder getestet → dann ging’s wieder mit allen Usern


Seltsamerweise habe ich im Nachgang alles wieder aktiviert und es geht immer noch - wie gesagt fast immer


Das ist ein wirklich seltsames Verhalten!!!

Probier’s mal aus - hoffe es hilft Dir auch!

Viel Erfolg
Thomas

17

Hallo,

ich habe das Problem gelöst! Es lag an einem nicht laufenden Cron Job. Dadurch haben sich viele (bei mir waren es 502) aktive Sitzungen angesammelt und die Anmeldung wurde dadurch verzögert. Was dann zu time-outs fĂŒhrte.

Jedenfalls habe ich nun auf dem Synology folgenden Befehl ausgefĂŒhrt:
“sudo docker exec --user “www-data” NEXTCLOUDCONTAINERNAME php -f /var/www/html/cron.php”

danach flutscht die Anmeldung wieder super zĂŒgig! Das ganze muss ich jetzt noch als geplante Aufgabe erstellen und ich denke ich hab dann Ruhe :slight_smile:

Gruß Blackmore

18

Hallo Blackmore,
ich habe deinen Lösungsweg ausprobiert - habe aber immer noch bei einem Benutzer die gefĂŒhlt ewig lange Anmeldezeit

Zumindest meldet er sich zuverlĂ€ssig an - habe dazu am Reverse Proxy die Zeit hochschrauben mĂŒssen

Also der Cron Job lĂ€uft, bekomme grĂŒne Anzeige 
 gerade eben ausgefĂŒhrt

Mal eine Frage, wo in der DB siehst Du diese aktiven Sitzungen?
ist das in der Tabelle oc_user_status?
Das wĂŒrde ich gerne mal kontrollieren

Danke fĂŒr Info
Gruß Thomas

19

Hallo,
heute habe ich endlich die Lösung dazu gefunden!
Sehr viele EintrĂ€ge in der oc_authtoken fĂŒr diesen Benutzer.
EintrĂ€ge gelöscht → alles wieder super!!
Gruß
Thomas

1 Like
20

Hallo Thomas,
Deine Lösung hat mich erstmal gerettet. Nachdem ich alle EintrĂ€ge eines blockierten Users in der oc_authtoken gelöscht hatte, fluppte die Anmeldung auch wieder. Und auch viel schneller als vorher. Bei einer Umgehung des Reverse Proxies funktionierte die Anmeldung auch vorher noch, aber mit mehreren Minuten Wartezeit. Damit ist wohl klar, daß die oc_authtoken den Anmeldeprozess verlangsamt und dieser dann am Timeout des Proxies scheitert.

Aber eine endgĂŒltige Lösung scheint mir das nicht zu sein. Warum?

  1. Ich habe vorher zahlreiche Sitzungen in den Einstellungen des Users gelöscht. Dadurch waren die EintrĂ€ge in der oc_authtoken bereits deutlich reduziert, ohne das das eine Änderung gebracht hĂ€tte.

  2. Punkt 1 bringt mich darauf, daß es möglicherweise nicht an der Anzahl der EintrĂ€ge liegt, sondern an einem speziellen. Leider kann ich jetzt nicht mehr herausfinden, an welchem.

  3. Durch das Löschen aller authtokens sind natĂŒrlich auch alle verknĂŒpften Sessions verloren gegangen und ich musste sie alle wieder mĂŒhsam neu erstellen. Könnte man Punkt 2 erhĂ€rten und lösen, wĂ€re dieser Aufwand ĂŒberflĂŒssig.

  4. Der manuelle Eingriff in der DB scheint mir mittelfristig nicht als regulĂ€re Lösung zu taugen. Da muß doch noch irgendwo ein Problem hinter stecken.

Was werde ich nun tun. ZunĂ€chst einmal freue ich mich, daß alles wieder lĂ€uft. Aber ich fĂŒrchte, das Problem wird zurĂŒckkehren. Dann werde ich mir die EintrĂ€ge in der oc_authtoken mal genauer ansehen - falls nicht jemand anders hier vorher die Lösung verrĂ€t 


@Blackmore: der Cronjob lĂ€uft bei mir regelmĂ€ĂŸig. Damit konnte ich das Problem nicht beheben.

Viele GrĂŒĂŸe
Achim