Page MenuHomePhabricator

Install error: 1044 Access denied for user
Closed, ResolvedPublic

Description

Author: bobcat

Description:
Here's my error message I keep getting. My ISP says it's an error on the
softwares' side, I called BS but who are they to listen to reason?

The username is not '@%' as shown below, BTW.

  • PHP 4.3.6: ok
  • Warning: PHP's register_globals option is enabled. MediaWiki will work

correctly, but this setting increases your exposure to potential security
vulnerabilities in PHP-based software running on your server. You should disable
it if you are able.

  • PHP server API is cgi; using ugly URLs (index.php?title=Page_Title)
  • Have XML / Latin1-UTF-8 conversion support.
  • PHP's memory_limit is 8M. If this is too low, installation may fail!

Attempting to raise limit to 20M... ok.

  • Have zlib support; enabling output compression.
  • Neither Turck MMCache nor eAccelerator are installed, can't use object

caching functions

  • GNU diff3 not found.
  • Found ImageMagick: /usr/local/bin/convert; image thumbnailing will be

enabled if you enable uploads.

  • Found GD graphics library built-in.
  • Installation directory: /usr/local/psa/home/vhosts/sleestak.net/httpdocs/wiki
  • Script URI path: /wiki
  • PHP is linked with old MySQL client libraries. If you are using a MySQL

4.1 server and have problems connecting to the database, see
http://dev.mysql.com/doc/mysql/en/old-client.html for help.

  • Trying to connect to MySQL on localhost as root... o Connected as root (automatic)
  • Connected to 4.0.16-globat; enabling MySQL 4 enhancements o Error selecting database sleestak_wiki: 1044 Access denied for user:

'@%' to database 'sleestak_wiki'


Version: 1.5.x
Severity: normal

Details

Reference
bz3914

Revisions and Commits

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 8:55 PM
bzimport set Reference to bz3914.
bzimport added a subscriber: Unknown Object (MLST).

robchur wrote:

The error text clearly states what the issue is. You're likely using a newer
mySQL version with an older version of PHP. So it's a server-side issue. There
are workarounds, such as setting the password to be in the "old" form, but at
the end of the day, it's probably better to get the client libraries PHP is
using updated.

bobcat wrote:

My Host still blames the software for the problem, Rob. I appreciate any more
help as i've been trying to get this damn thing up and running for over 3 weeks
and my users are getting restless in order unleash the power of wiki! - jason

"Dear Valued Customer,

That doesn't change what I've said. You do not have root access to the database.
If we're going to get into what the software is "clearly saying" then please see
that the software clearly says that it is trying to access the database as root.
You do not have root access to the database. If you try to access the database
as root, you will not gain entry. The software is reporting that it tried
accessing the database as root and was unsuccessful.

Please give them this information. I see from the support article that all you
told them was that your ISP says it's on the software side and that you didn't
give them any more information than that. If tell them what I'm telling you,
they'll be able to help you correctly configure this software. I'm sure that
they're assuming when they wrote that reply that you should have root access to
the database.

Also, if you come to them from the angle that "I called BS but who are they to
listen to reason?" then they're likely to just assume that your ISP is being
unreasonable and not give much merit to the problem.

Nobody on this end is trying to "BS" you, and it's pretty insulting to see that
said, especially since the information I gave you is accurate but was
disregarded. We've given you the information that you need to see this problem
resolved.

Thank you for contacting our technical support. If you have any further
questions, please reply to this email leaving all text intact, and be sure to
give us a detailed description of how we can further assist you.

Best regards,

Johnny
Globat Signature Support - Tier 2
Web Hosting Made Easy®
support@globat.com
http://www.Globat.com/

How well did we do at responding to your request? Please let us know at this link:
http://www.zoomerang.com/survey.zgi?RYT27QJ83RVVPB7LQ1G60P33

On Thu, 10 Nov 2005 07:54:31 -0800, bobcat@sleestak.net wrote:

Here's my answer from the developers:

http://bugzilla.wikimedia.org/show_bug.cgi?id=3914"

It looks like their server is misconfigured with a bogus 'root' user, which allows
logins but then doesn't let you do anything. If the root login had *failed*, then the
system would continue on to use the specific account you gave it.

(MediaWiki is designed primarily for systems operated by the wiki operator, and will
try to log in as root and *create* the user you specify. If the root login fails, it
assumes you're on some limited account and hopes the account already exists.)

If they can't fix their broken root login, you'll need to poke around in config/
index.php and disable that bit.

robchur wrote:

If you've been leaving the root password box blank, as expected, it might be
worth a try just to shove some utter crap in there and hope it's rejected by the
mySQL server. MediaWiki's installer is, as Brion said, designed to be run by the
operator themself in about nine tenths of cases. However, it will attempt to use
the other user account information provided if root access is denied.

Your web host is misinterpreting how the software works, although to be fair, if
their server is allowing MediaWiki to think it can connect as root, it won't
display a problem until it finds root can't *do* anything; but it won't then
attempt to use the limited account credentials you supplied previously. Perhaps
it's worth us tweaking this bit in the installer...?

bobcat wrote:

Thanks Rob and Brion for the advice, I went into config/index.php and tried to
enter some utter crap to no avail. Also cut out the database check routine...
no dice.

I might be so bold to say that maybe this does happen more often with users
attempting to install on an ISP's server rather than their own. It just happens
that I see to always find a way to break things (damn testing background) and
I'm pretty vocal about even the most minor details.

If there's any other workarounds, I'm all ears. Textpad is open willing and
ready. -Jason

bobcat wrote:

I reopened this bug as I don't believe it is 'invalid' and it is definately not
'fixed' either. The program still will not install and I am sure there has got
to be an easy workaround.

It's a week later and i'm still hoping to get this launched on the 1st for my
users like I promised. I have been hyping up wiki for a while and it would
really really stink to have it all backfire on me.

Like I said, i'm not too good with SQL / PHP, I can edit stuff and replace so
any help would be really really helpful so I don't have to eat crow!

-jason
bobcat@sleestak.net

robchur wrote:

As a bug, which affects all our users, it's invalid, because it only basically
affects you. Brion also told you what you need to do - modify the bit of
config/index.php which uses root if it can. I might post details on how to do
this shortly.

Rob, it is a general problem in that a number of people have encountered this.
I believe there's another bug report open for making the attempted 'root'
username selectable in the installer interface (possibly with a patch, but if
so it might be out of date).

robchur wrote:

I'll poke about and see if I can come up with a patch for it.

robchur wrote:

Workaround:

  1. Edit config/index.php
  2. Comment out lines 502-509 and lines 511-523 inclusive.
  3. Save, upload
  4. Re-run the installer

Note: Haven't tested these modifications, but those appear to be the lines which
do the root stuff. With luck, this should sort you.

robchur wrote:

*** This bug has been marked as a duplicate of 921 ***

bobcat wrote:

Rob that workaround never did anything. I have been waiting for an update
patiently of sorts over the last month, but nothing has surfaced.. please help!

robchur wrote:

Sooner or later, and probably sooner, I'm going to give in to the burning
temptation to re-do the installer completely. Brion's just waiting for it, I
know. ;-)

When that happens, this is one of the things I hope to address.

jun wrote:

i also have this problem. using MediaWiki 1.5.6.

from my local slackware 10.2 linux box.

MediaWiki 1.5.6 installation

Please include all of the lines below when reporting installation problems.
Checking environment...

  • PHP 4.4.0: ok
  • PHP server API is apache; ok, using pretty URLs (index.php/Page_Title)
  • Have XML / Latin1-UTF-8 conversion support.
  • PHP's memory_limit is 8M. If this is too low, installation may fail!

Attempting to raise limit to 20M... ok.

  • Have zlib support; enabling output compression.
  • Neither Turck MMCache nor eAccelerator are installed, can't use object

caching functions

  • Found GNU diff3: /usr/bin/diff3.
  • Found ImageMagick: /usr/bin/convert; image thumbnailing will be enabled if

you enable uploads.

  • Found GD graphics library built-in.
  • Installation directory: /var/www/htdocs/wiki
  • Script URI path: /wiki
  • Connecting to wiki on localhost as ...success.
  • Connected to 4.1.14; using enhancements for mySQL 4. o Error selecting database wiki: 1044 Access denied for user

''@'localhost' to database 'wiki'

and my webhost somewhere:

Checking environment...

  • PHP 4.3.10: ok
  • Warning: PHP's register_globals option is enabled. MediaWiki will work

correctly, but this setting increases your exposure to potential security
vulnerabilities in PHP-based software running on your server. You should disable
it if you are able.

  • PHP server API is apache; ok, using pretty URLs (index.php/Page_Title)
  • Have XML / Latin1-UTF-8 conversion support.
  • PHP is configured with no memory_limit.
  • Have zlib support; enabling output compression.
  • Neither Turck MMCache nor eAccelerator are installed, can't use object

caching functions

  • Found GNU diff3: /usr/bin/diff3.
  • Found ImageMagick: /usr/bin/convert; image thumbnailing will be enabled if

you enable uploads.

  • Found GD graphics library built-in.
  • Installation directory: /home/morofoci/public_html/wiki
  • Script URI path:
  • PHP is linked with old MySQL client libraries. If you are using a MySQL

4.1 server and have problems connecting to the database, see
http://dev.mysql.com/doc/mysql/en/old-client.html for help.

  • Connecting to morofoci_wiki on localhost as ...success.
  • Connected to 4.0.25-standard; using enhancements for mySQL 4. o Error selecting database morofoci_wiki: 1044 Access denied for user:

'@localhost' to database 'morofoci_wiki'

jun wrote:

if i use the root access on MySQL on my Slackware 10.2 Linux box. Its OK!

Checking environment...

  • PHP 4.4.0: ok
  • PHP server API is apache; ok, using pretty URLs (index.php/Page_Title)
  • Have XML / Latin1-UTF-8 conversion support.
  • PHP's memory_limit is 8M. If this is too low, installation may fail!

Attempting to raise limit to 20M... ok.

  • Have zlib support; enabling output compression.
  • Neither Turck MMCache nor eAccelerator are installed, can't use object

caching functions

  • Found GNU diff3: /usr/bin/diff3.
  • Found ImageMagick: /usr/bin/convert; image thumbnailing will be enabled if

you enable uploads.

  • Found GD graphics library built-in.
  • Installation directory: /var/www/htdocs/wiki
  • Script URI path: /wiki
  • Connecting to wiki on localhost as root...success.
  • Connected to 4.1.14; using enhancements for mySQL 4.
  • Database wiki exists
  • Creating tables... using MySQL 3/4 table defs... done.
  • Initializing data...
  • Created sysop account wyzemoro. *

    Initialising "MediaWiki" namespace... Clearing message cache...Done.

    Creating LocalSettings.php...

the problem is how can it be fix like in my shared hosting were i dont have root
access?

robchur wrote:

The output from comment #14 looks to me like no username was entered in the
regular database username field, and that the superuser account details were
left to the defaults (i.e. "don't use") meaning that the installer tried to
connect with a blank username.

Diffusion added a commit: Unknown Object (Diffusion Commit).Mar 4 2015, 8:16 AM