Locale issue prevents login

When I try to log in, nextcloud reports:
Setting locale to en_US.UTF-8/fr_FR.UTF-8/es_ES.UTF-8/de_DE.UTF-8/ru_RU.UTF-8/pt_BR.UTF-8/it_IT.UTF-8/ja_JP.UTF-8/zh_CN.UTF-8 failed

  • Please install one of these locales on your system and restart your webserver.

I was using a NC16.0.1 on a MageIA6 which was correctly running. I have upgraded to MageIA7 and now my nextcloud reports this error.
My locales are installed AFAIK. I have the error message in French if I do not force the language to en (which I did to generate this ticket).

So far, I cannot say if the issue is a nextcloud or a system one, but I do not have any clue so far to diagnose, this is why I request for some help.

As I do not have access to the GUI, I cannot even try to update to 16.0.2 (not sure it is a good idea) or check anything there. I have seen that it is possible to skip the locale check in order to move on, but I do not know how to do it.

Thanks in advance

1 Like

I have just updated to 16.0.2 using CLI (my first try, flawlessly), the issue remains…

16.0.3 : issue still there

Same issue with NC14 and also with NC15 after upgrade to ubuntu 19.04 with php 7.2.19.

I reviewed carefully locales and they are fine.

As www-data user:

$ locale
LANG=en_US.UTF-8
LANGUAGE=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=en_US.UTF-8

Locales lang manually generated:

$ locale-gen en_US.UTF-8

Was a testing machine, so I load every locale to be sure and “locale -a” show the full list.

locale -a | grep en_US.utf8

Also try with dpkg-reconfigure locales, forcing php.ini with intl, setting nextcloud default/force_locale vars, etc. without any luck.

Locale set globally to “en_US.utf8” with same results:

$ localectl set-locale LANG=en_US.utf8

(Even editing “/etc/environment” manually)

Full packages purged and reinstalled and still the same:

$ sudo apt-get install --reinstall language-pack-en

After every change I made multiple apache reloads and reboots as well as full server’s and nothing changes.

Then I check the code and looks like the lock was generated by “isSetLocaleWorking()” function returning false:

I checked setlocale() php function with my own php script and was working fine.

So then I forced the function to return “true” and the message disappear and I could login and work without any trouble.

I know it’s far from be a real solution (we still don’t know why the function returns false and I’m worried about collateral effects in filenames, metadata and so on) but probably it will help developers to point us in the right direction.

Thanks a lot for your time,
m.

PD: Just in case somebody else have trouble dealing with locales, here you have a nice resource (Debian flavour): https://www.rosehosting.com/blog/configure-system-locale-on-debian-9/

“Nuremberg University of Technology Georg Simon Ohm” 's patch works fine to me:

I confirm the same as Mark: I forced the return to true earlier today and nextcloud was back online. I also agree it is not a solution, neither an acceptable workaround as I do not know the side effects.

I tried to debug further, but I am not php dev so I failed.

I do not undrstood the second post: what did you do?

EDIT: I am using php 7.3.6

PHP 7.3.8 and NC 16.0.4: issue remains

Hi @HomeBoy38

I believe it must be some issue with the system configuration. I ran NC on Ubuntu 16 and 19, ArchLinux, Raspi and never came accross this issue.
Unfortunately, I have no idea what the root cause of this issue might be, but I don’t believe it is related to (different versions) of Nextcloud.

Okay, read a bit on the Internet and it seems to be an issue with packages and maybe debian buster.
Please read this:

If that doesn’t help you solve the problem, a workaround has been found here:

I hope at least this helps for now. Good luck.

This is a real pain… Also seeing it on a Fedora30 installation.

@dag: we have found under MageIA7 that the issue seems to occur after an upgrade, not after a fresh installation. Do you have the issue after a fresh Fedora installation?

Someone found that the issue seems to be php 7 related rather than nextcloud as he was able to generate a simple php code and the setlocale function did not translate the date.

I do not have any clue how to investigate and find what could be the root cause

[root@machine ~]# urpme apache-mod_perl
To satisfy dependencies, the following 4 packages will be removed (3.6MB):
apache-mod_perl-2.0.10-6.mga7.x86_64
perl-SOAP-WSDL-3.3.0-4.mga7.noarch
(due to missing perl(APR::Table),
due to missing perl(Apache2::Const),
due to missing perl(Apache2::Log),
due to missing perl(Apache2::RequestIO),
due to missing perl(Apache2::RequestRec))
task-lamp-3-7.mga7.noarch
(due to missing task-lamp-perl)
task-lamp-perl-3-7.mga7.noarch
(due to missing apache-mod_perl)
Remove 4 packages? (y/N) y
removing apache-mod_perl-2.0.10-6.mga7.x86_64 perl-SOAP-WSDL-3.3.0-4.mga7.noarch task-lamp-3-7.mga7.noarch task-lamp-perl-3-7.mga7.noarch
removing package perl-SOAP-WSDL-3.3.0-4.mga7.noarch
1/4: removing perl-SOAP-WSDL-3.3.0-4.mga7.noarch
#############################################
removing package task-lamp-1:3-7.mga7.noarch
2/4: removing task-lamp-1:3-7.mga7.noarch
#############################################
removing package task-lamp-perl-1:3-7.mga7.noarch
3/4: removing task-lamp-perl-1:3-7.mga7.noarch
#############################################
removing package apache-mod_perl-1:2.0.10-6.mga7.x86_64
4/4: removing apache-mod_perl-1:2.0.10-6.mga7.x86_64
#############################################
[root@machine ~]# service httpd restart
Redirecting to /bin/systemctl restart httpd.service

=> this solves my issue, maybe something similar on other distributions?
=> I will leave this thread open a little more to see if other people confirm this as a solution and/or if someone has an explanation

Dag: can you please confirm on your side if mod_perl is installed on your side and if its removal solves your issue too? I have a confirmation from someone else under MageIA and maybe a third person? It could be a good start if we can also confirm it under another distribution?

Thanks for the hint for the perl modul, i have the same local-error-message issue on one of my nextcloud sites. Other sites does not provided this error behaviour. I checked installed php version, environment settings, database vesion, regenerate locales, setting up LANG, … no success… But:

After a2dismod perl solved the problem… -> Big Thanks for the perl hint again :slight_smile:

But i need the perl internpreter under apache2, too -> so i ordered the load of this module at the end:

cd /etc/apache2/mods-enabled
mv perl.load z_perl.load
systemctl apache2 restart

And now working both of them: nextcloud and the other perl-based webapp…

(i did not have time to analyse why the “natural” order of module-loading has this misstake…)

Unfortunatelly the reorder of the loading of perl (-> z_perl) not helped, because after the first “login”/“using” of the perl application, the location will be broken again in NExtCloud.

I can solve the problem only so, that I disabled the perl module and the perl-applicaiton setuped to use the mod_fcgid and not the mod_perl…