Dateien mit Umlauten werden ignoriert

Ubuntu Server 17.10, Nextcloud 12.0.4 stable, MySQL 5.7, PHP 7.1

Dateien die ohne Nextcloud im Filesystem erstellt werden (zB durch Download) und einen Umlaut enthalten, werden in der Files-App nicht angezeigt und auch durch occ files:scan ignoriert.
Dateien und Ordner, die über die Files-App erstellt werden und Umlaute enthalten sind in Ordnung.

Ich habe schon mit den Charsets rumgespielt: Apache und PHP verwenden per default UTF8. In MySQL habe ich die Datenbank extra mit UTF8-Charset neu angelegt (Default war Latin1). Leider ohne Änderung.

Jemand eine Idee?

Im Debug-Log finde ich noch folgende Einträge, während des File-Scans:

{“reqId”:“X7LIb2Ci8jdOOkqp3leZ”,“level”:0,“time”:“2017-12-26T17:25:29+01:00”,“remoteAddr”:"",“user”:"–",“app”:“OC\Files\Cache\Scanner”,“method”:"–",“url”:"–",“message”:"!!! Path ‘Serien/Zoo/S02E06.Sex, L\u00fcgen und Quallen.mp4’ is not accessible or present !!!",“userAgent”:"–",“version”:“12.0.4.3”}

{“reqId”:“X7LIb2Ci8jdOOkqp3leZ”,“level”:0,“time”:“2017-12-26T17:25:29+01:00”,“remoteAddr”:"",“user”:"–",“app”:“OC\Files\Cache\Scanner”,“method”:"–",“url”:"–",“message”:"!!! Path ‘Serien/Zoo/S02E10.H\u00f6lle in Helsinki.mp4’ is not accessible or present !!!",“userAgent”:"–",“version”:“12.0.4.3”}

{“reqId”:“X7LIb2Ci8jdOOkqp3leZ”,“level”:0,“time”:“2017-12-26T17:25:29+01:00”,“remoteAddr”:"",“user”:"–",“app”:“OC\Files\Cache\Scanner”,“method”:"–",“url”:"–",“message”:"!!! Path ‘Serien/Zoo/S02E12.Die S\u00e4belzahnkatze.mp4’ is not accessible or present !!!",“userAgent”:"–",“version”:“12.0.4.3”}

{“reqId”:“X7LIb2Ci8jdOOkqp3leZ”,“level”:0,“time”:“2017-12-26T17:25:29+01:00”,“remoteAddr”:"",“user”:"–",“app”:“OC\Files\Cache\Scanner”,“method”:"–",“url”:"–",“message”:"!!! Path ‘Serien/Zoo/S02E09.Das Knochenr\u00e4tsel.mp4’ is not accessible or present !!!",“userAgent”:"–",“version”:“12.0.4.3”}

Ich kann dir glaub da nur einen tipp geben

der fehler betrifft die MSQL und er codierung deiner DB
frag mich jetzt bitte nicht welche die richtige ist für dein problem :wink:

Hattest du das hier gelesen?
CREATE DATABASE db_name CHARACTER SET utf8 COLLATE utf8_general_ci

Das dürfte genau das sein, was du meinst. Oder sprichst du noch von was anderem?

das hat nur bedingt damit zu tun geh mal in die MYSQL db mit phpmyadmin und schau da mal nach was die datenbank sagt zu cloud welches der codierungen sie dort verwendet UTF8-…

Hat jemand eigentlich mittlerweile eine Lösung hierfür? Ich habe das Problem seit 3 Jahren und jedes Mal wenn ich mir denke “Jetzt packe ich das an!” wird es doch wieder nichts.

Hier ist meine aktuelle Konfiguration:

LC_ALL=de_DE.UTF-8
LANGUAGE=en_US.UTF-8

(sämtliche Kombinationen aus en_GB, en_US, de_DE und UTF-8, ISO* bewirken hier keinen Unterschied, doch mit den oberen Einstellungen habe ich Umlaute-Support über Bash und SSH)

Meine /etc/mysql/my.cnf ist direkt von den Nextcloud-Docs kopiert. Hier die wichtigen Zeilen:
[mysqld]
character_set_server = utf8mb4
collation_server = utf8mb4_general_ci

Desweiteren habe ich Support für Umlaute in Dateien:

darkn@darknpi:~ $ echo $LC_ALL
de_DE.UTF-8
darkn@darknpi:~ $ echo $LANGUAGE
en_US.UTF-8
darkn@darknpi:~ $ touch äöü
darkn@darknpi:~ $ file äöü 
äöü: empty

Ich kann die betroffenen Dateien innerhalb dieser Umgebung bearbeiten und jedes Umlaut mit der Tastatur neu tippen, doch bewirkt das keinen Unterschied.

Allgemein: Dateien mit Umlauten synchronisieren auch ohne Probleme, doch werden wie bei @loeffelpan beschrieben alle, die im Dateisystem erstellt wurden und durch occ files:scan --all aufgegriffen werden sollten, ignoriert. In der Datenbank sehe ich auch Einträge mit Umlauten und ich habe bereits die Tabellen testweise zu folgenden Collations konvertiert, ohne Verbesserung:
utf8mb4_general_ci, utf8mb4_german2_ci, utf8_german2_ci. Ich sehe ebenfalls Dateien mit Umlauten in der Datenbank:

MariaDB [nextcloud]> SELECT path FROM oc_filecache WHERE path LIKE "%ä%" LIMIT 1;
+----------------------------------------------------------------------------------+
| path                                                                             |
+----------------------------------------------------------------------------------+
| files/Desktop/Vivi/Reservierungsbestätigung.pdf  |
+----------------------------------------------------------------------------------+
1 row in set (0.022 sec)

Es macht ja eigentlich nur Sinn, wenn die PHP-CLI-Einstellungen von mir falsch sind. Finde aber nicht wirklich hilfreiche Parameter, die ich in php*.ini Dateien bearbeiten könnte.

Das Problem besteht auch nur auf Raspbian (Kernel 5.10.63-v7l+). Unter CentOS 7 Defaults habe ich mit denselben genannten Einstellungen keine Probleme.

Hat jemand das Problem erfolgreich gelöst und kann einen Hinweis geben? Vielen Dank!

Na also, habe es lösen können. Meine Befürchtungen haben sich bewahrheitet:
PHP nutzte bei mir nicht standardmäßig die System-Locale.

Ich habe dazu folgendes getan:

  1. Sicherstellen, dass de_DE.UTF-8 installiert und verfügbar ist (auskommentieren / hinzufügen in /etc/locale.gen und anschließendes locale-gen)

  2. Default locale für php-cli setzen (habe es auch direkt für php-fpm gemacht, man weiß ja nie):
    Bearbeiten der php-cli/php.ini bzw. php-fpm/php.ini:
    intl.default_locale = de_DE.UTF-8
    Achtet dabei darauf die richtige Datei zu bearbeiten. Ich nutze beispielweise als PHP-Handler in NGINX PHP 7.4, aber im Terminal PHP 8.0. Im Terminal php --version sollte die CLI-Version anzeigen.

  3. Das occ-Skript required console.php. In console.php habe ich die Locale auf den Systemstandard geändert, indem unter die use-Zeilen ein
    setlocale(LC_ALL, NULL);
    eingefügt wurde. Ich habe das Testweise mal ausprobiert, indem ich stattdessen
    echo("Locale: " . setlocale(LC_ALL, NULL));
    eingefügt hatte. Dabei habe ich dann endlich de_DE.UTF-8 als Output erhalten.
    Stellt aber sicher, dass ihr nur setlocale schreibt und nichts echo’ed, da in folgenden Zeilen teilweise weitere Headerdaten gesetzt werden, was nach einem Echo nicht erlaubt ist.

Ab hier hat dann occ keine Fehler mehr geworfen und die Dateien werden endlich richtig eingebunden. Ich werde mal die Tage ein Issue erstellen und den Vorschlag geben, das als Default in Nextcloud zu haben.

@loeffelpan Vielleicht hilft dir das ja auch

1 Like