Locale issue prevents login

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…)

1 Like

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…

Hi!
Some time since I have been here. …
Unfortunately I really need mod_perl in my system and cannot disable it. During the weekend I can test if a temporary disable solves the problem though.

I had the same problem here (NextCloud 18.0.3, Raspbian 10.3). After enabling an Apache Virtual host with Perl. I installed libapache2-mod-perl2. After that Nextcloud gave the “Setting locale error”.
Solution: apt remove libapache2-mod-perl2, no Apache2 restart required.

1 Like

I got this error after updating ubuntu server to 20.04.01 LTS
removing libapache2-mod-perl2 worked. I hope it will not have any side effects.

I am not a coder, but I gather from this discussion that the problem is having a proper nextcloud/lib/base.php page. Does anyone have one that works with nextcloud 20 that I could download? I can’t see to find one on my own.

I found a solution to this problem by downloading nextcould 20.1 and unzipping it in a directory nextdoor to my running nextcloud and copying the base.php for there to my nextcloud. Now I that I solved that problem I am getting this more generic error message.

Thanks for pointing my toward your solution. I need help applying it. I tried cutting and pasting it into the util.php and that just broke the whole thing.

This still appears to be an issue, but here’s the file I had to modify to fix the issue to help anyone else in the future: lib/private/legacy/OC_Util.php
In function: public static function isSetLocaleWorking()
Make a new line above the first if statement and just put: return true;

@zontreck
This fixed the issue for me. great help
Ubuntu 20.04, NC 22.2.9

This solution worked for me. But it still is a bug.
I am using NC 27.1, installed yesterday.
This solved also my android app problem of complaining the server was in maintenance mode.

Thx for the help.

Hi Everyone,

Today I migrated my NC 27.1.7 instance from CentOS7 to Fedora39. After about 90 minutes of fruitless efforts I found this post. The mod_perl package is not installed on my CentOS7 box so the issue didn’t present there, but it was present on Fedora39 either from the cloud image or by package dependency.

Anyway disabling the module and restarting the Apache service resolved the issue for me.

tail -1 /etc/httpd/conf.modules.d/02-perl.conf
#LoadModule perl_module modules/mod_perl.so

Thank you.