For some odd reasons during install the database username is used to create tables, but in the config this username is preceded with oc_. That is not a valid user. It even is not the dtabase username that is used, but the Admin username that is entered in the first field.
In the config.php there is a new password generated by the installer. That password is not used to write the tables earlier.
Iâv tried a clean install with Nginx and Apache 2.4, PHP 7.3 and PHP 7.2. I use MariaDB10.
I started with 18.0.0, tried latest release 3, and then 17 and even 16 with the same results.
A clean install of Wordpress went fine, so what is hapening here?
From other topics I see this already an old issue that I never came accross on multiple other installations.
Please help fast. Iâm done with Nextcloud after more then 10 hours experimenting, searching a.s.o.
Youâre mixing-up different things. The user name is NOT used to prefix the database tables. The database prefix (âdbtableprefixâ) can be defined separately in the configuration and defaults to âoc_â.
One of the generated passwords: k4PH0Ii3GWyXyGbar3zhcbOQCmbGLb
The dbpassword is missing special characters that are needed by MySQL, but that password is not the password I entered. It is internaly generated by NC. (And I did not click on the icon to display the password visibleâŚ) The dbuser is wrong too. That should be Hendrik. Sometimes even the port seems to be set to 3306.
I did that. All required PHP modules are present. Settings .ini checked and edited.
B.t.w. The problem did not occure when updating multiple systems. The only warning I get is user.ini that I need to set memory for specific clients (checksum error). We do not want that serverwide.
Tried that. Password needs 12 char and special characters on the system. In the names no special characters. Even _ left out. I can try to change password settings on the system to try this. But I will first try installing it on a different server in the datacenter.
Tried this on the server that already hosts about 12 NC installations. No special characters in database password. The database is written and correct info in the config.php but,
it ends with an error âinternal server errorâ. The config file seems not complete.
The only thing could be [] chacters in the admin user password. The user folder has been created in the Data folder.
Next try âŚ
And without any special character, Server error âŚ
In the log file (data folder) is nothing written about âerrorâ of âserverâ. Only two-factor app is not activated and has âerrorâ text.
In the server log files is nothing written about errors âŚ
An exception occurred while executing âSELECT uid, displayname FROM oc_users WHERE uid_lower = ?â with params [âhenkâ]: SQLSTATE[42S02]: Base table or view not found: 1146 Table âcldkwalident.oc_usersâ doesnât exist
The table is not created at all, just a settings include table.
But there is the message: Je koos SQLite als database.
And I DID choose Maria and gave the parameters in. All that input was correct.
So after having tried 3 different server environments with various inputs that all give simmilar errors, I conclude there is a serious bug in the installer.
And for the developer: Deprecated call $.tooltip(âfixTitleâ) has been deprecated and should be removed âŚ
Ok. I did a new attempt on the server in the datacenter.
Empty database and NC folder.
Copy NC 18.0.1 to server folder.
Install without special characters and as database server: 127.0.0.1 without a port (the is only MariaDB active on this server) It ended up with an âinternal server errorâ.
But the config is now OK.
So I did a rare thing. I copied again all NC 18.0.1 files to the server except the config folder and gave an âoverwriteâ instruction in FileZilla.
And what happens: the âinternal server errrorâ is gone. It now opens as it should!
What is different from the other servers that I can not get NC to work on:
They have not only MariaDB and they use an other port setting then the default 3306 for the database.
The issue seems to be related to this thread: https://github.com/nextcloud/server/issues/11868
Indeed. That is he way it used to work. I never had these install problems before.
I think the problem has to do with the port. That port settings are needed on systems that have multiple database engines.