So sieht die Meldung aus
CSRF check failedHäufige Ursachen
- Session-Cookie wird nicht gespeichert, z. B. Secure-Cookie über HTTP hinter einem TLS-Proxy.
- Reverse Proxy ohne passende
overwriteprotocol- undtrusted_proxies-Einstellung. - PHP-Sessions können nicht geschrieben werden (Rechte auf
session.save_path, volle Platte). - Redis als Session-Speicher nicht erreichbar oder voll.
- Login-Seite zu lange offen, Session abgelaufen, oder Zugriff über zwei verschiedene Hostnamen.
Prüfen
- Prüfen, ob und wie das Session-Cookie gesetzt wird
curl -sI https://cloud.example.com/login | grep -i '^set-cookie' - Proxy-Einstellungen von Nextcloud anzeigen
sudo -u www-data php /var/www/nextcloud/occ config:system:get overwriteprotocol; sudo -u www-data php /var/www/nextcloud/occ config:system:get trusted_proxies - Session-Speicher von PHP anzeigen
php -i | grep -E 'session.save_(handler|path)' - Cache- und Redis-Konfiguration anzeigen
sudo -u www-data php /var/www/nextcloud/occ config:system:get memcache.distributed; sudo -u www-data php /var/www/nextcloud/occ config:system:get redis
Lösung
- Hinter einem TLS-Proxy
'overwriteprotocol' => 'https'und die Proxy-IP intrusted_proxiessetzen. - Immer denselben Hostnamen nutzen und
overwrite.cli.urlpassend setzen. - Session-Verzeichnis beschreibbar machen bzw. Redis prüfen:
redis-cli ping. - Browser-Cookies für die Domain löschen und die Login-Seite neu laden.
- Plattenplatz prüfen – ohne freien Platz scheitern Session-Dateien still.
Häufige Fragen
Ist „CSRF check failed“ ein Angriff?
In der Praxis fast nie. Es bedeutet, dass das Token aus dem Formular nicht zur aktuellen Session passt – meist durch eine verlorene oder neue Session.
Warum tritt es nur bei manchen Benutzern auf?
Häufig sind Browser-Erweiterungen, gesperrte Cookies oder ein Lesezeichen auf einen anderen Hostnamen schuld. Ein privates Fenster grenzt das schnell ein.