I have a problem with the MySQL root user in My MySQL setup, and I just can't for the life of me work out how to fix it. It seems that I have somehow messed up the root user, and my access to databases is now very erratic.
For reference, I'm using MAMP on OS X to provide the MySQL server. I'm not sure how much that matters though - I'd guess that whatever I've done will require a command-line fix to solve it.
I can start MySQL using MAMP as usual, and access databases using the 'standard' users I have created for my PHP apps. However, the root user, which I use in my MySQL GUI client, and also in phpMyAdmin, can only access the "information_schema" database, as well as two I have created manually, and presumably (and mistakenly) left permissions wide open for. My 15 or so other databases cannot be accessed my the root user. When I load up phpMyAdmin, the home screen says: "Create new database: No Privileges".
I certainly did at some stage change my root user's password using the MAMP dialog. But I don't remember if I did anything else which might have caused this problem. I've tried changing the password again, and there seems to be no change in the issue.
I've also tried resetting root password using the command line, including starting mysql manually with --skip-grant-tables then flushing privs, but again, nothing seems to fix the issue.
I've come to the end of my ideas, and would very much appreciate some step-by-step advice and diagnosis from one of the experts here!
Many thanks for your help.
I had the same issue: only one user account worked to access the mysql databases via the administration console or the query browser. When I used the skip-grant-tables suddenly all accounts could log in, including root.
I saw it as a bug as far back as 2006, but the final entry there isn't a command that can be executed when in skip-grant-tables mode, so I still hadn't solved the issue.
What helped me
This answer is similar to one described by Ben Bakelaar in the above link. The problem comes when your my.ini has the name resolution flag disabled (skip-name-resolve). This kills mysql's ability to resolve 'localhost' and the mysql.user table only has an entry for localhost / root.
Update your mysql.user table's localhost entry to be 127.0.0.1 instead, and you can log in to the local consoles even with the skip-name-resolve feature enabled.
Try starting the server with --skip-grant-tables and then checking the privilege tables in the mysql database:
select * from user where User='root';
select * from tables_priv where User='root';
select * from db where User='root';
You could also try:
show grants for root#localhost;
show grants for root#'%';
show grants for root#'hostname';
Once in you could do this to attempt to give root full privileges:
grant all privileges on *.* to root#localhost identified by 'password' with grant option;
Your comment shows your current root privileges (without --skip-grant-tables). It's fine that you do not have any entry for 'root'#'%', you do not have that by default and you can consider it a security measure.
It looks like you've messed up your 'root'#'localhost' privileges. GRANT ALL PRIVILEGES ON . is weird. Usually, you have something like GRANT ALL PRIVILEGES ON *.* or GRANT ALL PRIVILEGES ON myDatabase.myTable. Your GRANT does not specify the databases and/or tables to grant the privileges for. I have no idea how your client managed to produce it. I cannot reproduce it with the mysql commandline client (tried empty strings, whitespace, any kind of quotes...), mysql refuses the GRANT statement (which, of course, is the correct behaviour). Looks like MAMP is doing something really strange. Since I cannot reproduce a GRANT like yours, I cannot say how mysql interprets that, but I guess it has set the privileges to 'N' on the global level.
To fix it, you need a user with appropiate privileges. Usually, you have a user 'root'#'localhost' and a 'root'#'your-hostname'. If you're lucky, 'root'#'your-hostname' is still fine. Afair, mysql connections work as follows: If you connect to localhost, you connect as 'root'#'localhost' (not sure about 127.0.0.1, I guess it is also 'root'#'localhost'). If you connect to your-hostname, you connect as 'root'#'your-hostname'. If this user's privileges are still ok, you can update the privileges for 'root'#'localhost' and you are done.
In your comment, you say you cannot connect via 127.0.0.1 since the socket is in an unusual place. I guess you misinterpret the error. IIRC you connect via socket if you connect to 'localhost', but via TCP/IP if you connect to 127.0.0.1 or your-hostname. If mysql tries to connect via socket and cannot find the socket (because you did not specify the correct location), the error message mentions where mysql tried to find the socket. Your error message does not. I guess your error is a networking error. Maybe you've started the mysql-server with the --skip-networking option, or your configuration specifies an incorrect bind-address. You need to fix that first, otherwise you can't connect as 'root'#'your-hostname'.
Thats because MAMP and the command line mysql (and the mysql everything except MAMP) are different.
MAMP has its own built in mysql and you can't get to it via the command line, only the build in phpmyadmin.
this has been my experience, I have MAMP and use the other mysql for ruby on rails and other stuff.
Related
I've got a PHP app with Postgresql for the datastore, and just migrated the db to a new managed offering provider. Now when I try and run the app on my local development machine (macOS 10.12.6), I encounter the following error trying to connect to the newly situated db:
PDOException: SQLSTATE[08006] [7] could not open certificate file
"/var/root/.postgresql/postgresql.crt": Permission denied
There's a couple of interesting things about this:
If I try to connect to the same remote database via the psql client, I have no problem, it drops me straight into a psql prompt where I can query away at the DB to my heart's content.
I can execute PHP cli scripts that connect to the remote DB and query it without problem. PDO only throws an exception if I'm calling the connection code through a script invoked via an http request through a local Apache 2.4 server.
I am not at all shocked that permission is denied to access resources in /var/root, but I am shocked that anything expected to run in userland would ever be checking there. It seems like permission should be denied by default for its contents, even if there was a .postgresql/ subdirectory there (which there isn't).
#1 suggests this is not a pg_hba.conf or other client whitelist or network issue. #3 probably suggests perhaps I should have Apache switch to a non-root user, I'd guess, but beyond that I'm not sure what to make of it, and at any rate I have not placed a ~/.postgresql or postgresql.crt anywhere.
#2 suggests Apache2+libphp7.so doesn't know where to look for postgresql client certs... but the php binary does? This feels like the big clue, but I have no idea why it would be the case or how to fix it.
What are some next steps I could take to figure out how to get the web app connecting?
EDIT:
Prompted by the comment by #jjanes below, it occurred to me to try two things:
a) changing the apache config so that it was running as my personal user to see if the connection worked
b) trying to make a psql connection as root to see if that worked
When both did, that suggested to me that maybe the error message isn't complaining that it can't find a certificate for root (but somehow knows where to look for my personal account), it's that it's freaked out that it couldn't even muster permissions to check under /var/root.
So I did chmod /var/root o+x and mkdir /var/root/.postgresql/ and... it's fine. It didn't need the cert, just needed to have permission to look for it.
This feels like a bug for the sslmode=require level of things, but I'm happy to have a workaround. And I'd still be interested to hear suggestions of other ways to address situations like it.
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 7 years ago.
Improve this question
$con = mysqli_connect('<remote server ip address>','root','*******','CSV_DB',);
if (!$con) {
die('Could not connect: ' . mysqli_error($con));
}
I have a simple program to connect to a mysql server that I created using phpmyadmin, however I get the 'could not connect' message every time I try to connect.
I know that it could be a number of different issues but I'm really looking for advice on how to troubleshoot.
When I ssh as root to the server I can access the server using the terminal and everything is fine. However this connection which uses the same username/password/db/etc and I can't seem to log in. Also, the mysqli_error never prints-not sure why.
Here is a quick quick checklist for enabling Remote Connections for MySQL but read (6) first. If I have missed anything, feel free to edit.
1) Your remote user is connecting through an account that was created with appropriate user,host entries (look at output from select user,host from mysql.user order by 1,2). If not, look into the CREATE USER and/or GRANT commands. Examine the output from SHOW GRANTS for the user.
2) You have done flush privileges; (Some say it is unnecessary, others say it is).
3a) Locate your mysql configuration file referenced in 3b) below by reviewing info in This Document (or for Windows, likely down the C:\ProgramData\MySQL\MySQL Server 5.NNN path). It varies by distro for Linux.
3b) You have modified and saved my.ini (Windows) or my.cnf (Linux) and changed bind-address away from 127.0.0.1 or localhost, in favor of 0.0.0.0. And you have created and rem'd out the following line: #skip-networking. It will look similar to this:
[mysqld]
bind-address=0.0.0.0
#skip-networking
4) Restart the mysql daemon. How one does this varies by distro.
5) Firewall issues. Make sure the port, default being 3306, is open to the outside world (which may in fact just be your intranet). This includes any other layers of firewalls, such as AWS EC2 Security Groups, or similar, if any.
6) Understand that there is a security risk associated with this. Unless you have knowledge of exposing your mysql server to remote connections, do not perform this.
7) Please run frequent security assessments with select statement listed in 1. above including reviewing the SHOW GRANTS for those users. Do not over-grant users with wildcard unnecessarily. Rather, give users the minimal privileges for them to get their work done.
8) Frequently examine failed connection attempts via the General Log and the Error Log as briefly introduced below.
For inbound, you can look at the general query log.
select ##general_log; -- a 1 indicates it is turned on for capture
select ##general_log_file; -- the file that it logs to
So all the queries can be logged to the General Query Log if the setting is turned on. Examine the log for "connect", but especially for Access denied for user to see failed attempts. Do this regularly (not every few years). I do it at least twice a day. Note, you can obviously automate the reporting through an external program. The outside world is going to pound your server to get in like the image below. It is a reality; brace yourself for it.
Check out the manual page for The Error Log too, noting warning levels, and verbosity settings based on your version.
I would recommend that one create a backup copy by date (named as such) and delete the log files after backup to start fresh after the backup. The log files can grow huge in size rapidly, especially the General Log. Don't forget whether or not you have the setting turned on or off for logging.
You can use the two logs to determine if your connection attempt made it past the firewall during the steps here.
I am making a website that I expect to be hosted on several servers. I want to be able to check to make sure the MySQL user that has been created on those servers has sufficient privileges so that I can give a clear error if one of the privileges that the MySQL user requires is missing.
I found the MySQL command SHOW GRANTS FOR CURRENT_USER but its output looks like it would require a bunch of work to parse.
Is there a better way to verify that the MySQL user has sufficient permissions?
Hi try using the select statement below instead of SHOW GRANTS.
SELECT * FROM mysql.user WHERE USER LIKE 'root';
Okay so heres the situation. I have just had to move servers due to budget cuts so the new server is a webfusion VPS. I am now getting an access denied error on all mysql queries. This is the specific error:
Access denied for user 'www-data'#'localhost' (using password: NO)
I do not know what is causing this. I have a database with the mysql username and password stored in a different php file. The username shown in the error is not the same as the actual ussername and I am using a password. It is my understanding that you can put your own php.ini file in the webfusions root and that will work. Is there something I have missed? I have been running on coffee today so that could be why. The mysql database is on the same server btw.
It could be a couple of things. I guess let's start with what is correct.
Your MySQL server address is correct and your webserver is able to connect to it. This should be a given since your webserver and MySQL server appear to be on the same machine.
The username you are using is www-data. That is the first thing I would check. Make sure that is the proper username.
Now check your password. It looks like you are trying to not have to use a password. Chances are that is incorrect (and if it is correct, you really should think about changing that).
Other than that, there is not much else that could be going wrong there. Are you intending to connect to the MySQL server that is on the same machine as your website?
Did you create the appropriate MySQL users after you migrated the database? Grant tables and user privileges are usually not transferred while doing a DB migration (unless you are using some specific tools like the ones provided by Percona etc.)
I have just started a LAPP machine from Amazon ec2. I have updated it to be Movable Type ready. I am using the postgresql database. I stopped at the database installation section because I was getting a postgresql error. I thought the only user by default is 'postgre' and has no password. I put that in MT and it complains that I don't have a password. So I thought I need to make a new user. So I tried createuser and it is asking for a Password. I then did sudo and was now root. It still wants a Password. I do not know what it is.
Looking at the log it appears postgresql is shutdown. When I try to restart it by using pg_ctl it says I cannot be root to restart it. So I exit and run it again as the default user name it gives me and I get a permission error.
When I try to be root and createuser or do psql it says I need to give a password. I have tried to just hit return, and a bunch of other passwords that it may be. No luck. I thought since I was root I should be good.
I know postgresql is there because MT says it is.
So I need to either come up with a psql Password or be able to login as a different user with the ability to restart postgresql.
When you are 'root', you could su to the postgres user. Then you should be able to create a new user. Remember to add the connection rights to the user in the /etc/postgresql//main/pg_hba.conf.