I found this answer here, but still can't create a new Database.
I was also told that the default the password for root is blank, that didn't work, tried password, root etc :(
I'm stuck at the password screen.
The only thing I can gather is that the default ip I was given doesnt work.
Check that mysql is running on server 127.0.0.1
Check that mysql is
running on port 3306 (note: 3306 is the default, but this can be
changed)
According to this tutorial on their site, I need to check that mysql is running on the right server ip, but how do I even do that? :(
Looks like the first problem here is the login. If blank as password is not working for you. Try to set a password first and then proceed with next steps
Here are instructions to reset/set the password for first time
http://dev.mysql.com/doc/refman/5.5/en/resetting-permissions.html
Or use
mysqladmin -u root password NEWPASSWORD
Once you are logged in you can easily create a database.
Related
I just installed MySQL just now so I shouldn't have been able to place a password beforehand.
This appears when I try to test the connection:
Then if I leave it blank, it errors.
I also tried 'root' as password and 'admin' just to try a few and it still errors. I try to type mysql -u root -p in MySQL shell but it keeps saying i'm not connected. I'm lost.
It doesn't know until after it connects whether there is a password or not. That's because it needs the password to connect. So it always asks for one.
I think the problem you have is that there is a subtle difference between no password and a blank password and because you're not entering one, the connection is being made with no password when perhaps you've set a blank one.
Perhaps try to find the MySQL CLI client for Windows and look at the --password option.
I know there are a million questions like this where the answer ends up being that the user forgot to use the correct password, or didn't know to connect to 'localhost' as the DB server or something stupid. This is not one of those questions.
When I SSH into my server from a terminal, I'm able to connect fine. From there, I can run:
mysql -h localhost -u MyUser -pMyPassword
I can get into the DB just fine from the terminal.
Using Navicat, I've set up an SSH tunnel. I've done this a thousand times before and know exactly how it works.
On the SSH tab, I put in the REMOTE hostname. Port 22. Username is the username that I use to SSH, NOT the database username. I've used both a password and a public key. Both work fine.
The problem seems to be the connection to the database after the SSH tunnel is established.
On the general tab, I have the hostname set to 'localhost'. The username is MyUser, the same username which works with the mysql command in the terminal. The password is saved, and is MyPassword, the same password which works with the mysql command in the terminal. The encoding is set to UTF-8, the default.
I've double-checked all these values a thousand times, they match exactly what works from a terminal.
The error I get is:
Access denied for user 'MyUser#127.0.0.1' (using password: YES)
It's clear from this message that the SSH tunnel works, but the connection to the database does not. Again, the values on my general tab match the values I use in the mysql terminal command (which works) exactly, but Navicat won't connect.
I've also tried using 127.0.0.1 as the host. This produces the exact same error. It's curious to me that setting a hostname of 'localhost' throws the error with 127.0.0.1 instead of localhost, but I assume this is just set up in the server's host file and is essentially the same thing.
I've tried this with 'Use Compression' both checked and unchecked, though unchecked is the default value.
I've also double-checked my general tab against the configuration in a webapp which runs off the server, and it is identical. The only things I can think are:
-MySQL is not running on port 3306 (though I wouldn't expect an access denied error if no server existed on this port to begin with).
-UTF-8 default encoding is incorrect (though every single table in the DB is set to utf8_unicode_ci)
Those are the only two things left which I could change, as the username and password are correct.
I also read a guide which said to check the server's /etc/ssh/sshd_config file, and look to see if there's AllowTcpForwarding set to no. This value does not exist in that file, and I was told that the default value is yes, so I haven't added the value.
It's worth mentioning that this is a MariaDB database, and I have the connection set to use MySQL in Navicat. I've successfully connected to MariaDB databases using the MySQL setting in the past, so I don't think should cause any issue.
I'm using homestead and trying login to my mysql database via phpmyadmin. I have used same settings couple years already.
Yesterday I started working and I run the command homestead up - but this time everything seemed a bit different than usually. For example, vagrant insecure key detected and then vagrant automatically replace that with a newly generated keypair - okay, thats not bad, and I guess thats completely fine.
After that its stop and start nginx and php5-fpm nine times and then comes ==> default: mysql:
==> default: [Warning] Using a password on the command line interface can be insecure.
==> default: Please use --connect-expired-password option or invoke mysql in interactive mode.
The SSH command responded with a non-zero exit status. Vagrant
assumes that this means the command failed. The output for this command
should be in the log above. Please read the output to determine what
went wrong.
Okay, well I logged in homestead ssh and then mysql -u homestead -p password and set the new password. No errors thrown. Great.
Then I tried to log in my database phpmyadmin.app with the homestead username and new password but.. for some reason my databases are disappeared.
Well... after great Google search session I noticed when I write mysql> select * from mysql.user; command, there is two homestead users. First one is under 0.0.0.0 ip and second is under % - I'm pretty sure that this causes my problem one way or another, because the homestead user which uses % is made same day when this problem first time occurred.
Or.. I'm completely wrong direction and the problem causes for different reason(s). Whatever the case, I'm here to ask some help from a bit smarter guys than me.
Should I remove the second homestead user, or what would you suggest?
I really appreciate your time.
First see my mysql answer for a related issue.
For these kinds of problems with Laravel Homestead, I recommend throwing away and reinitializing the Vagrant box. Homestead is just a sandbox (as long as you back up your client machine data, there is no harm in rebuilding the sandbox).
First, back up any MySQL databases or other client machine information with a tool like mysqldump or Sequel Pro, as it will be lost when your box is re-provisioned.
Then:
# from host machine
cd ~/Homestead
vagrant destroy
vagrant box prune
vagrant up --provision
# if still seeing MySQL errors during provisioning, do the steps in https://stackoverflow.com/a/46106953/539149 or:
vagrant ssh
# log into mysql (for Homestead your password is likely "secret")
mysql -h localhost -u homestead -p
SET PASSWORD = PASSWORD('secret');
-- A) set password to never expire:
ALTER USER 'root'#'localhost' PASSWORD EXPIRE NEVER;
-- or B) to change password as well:
ALTER USER 'root'#'localhost' IDENTIFIED BY 'new_password', 'root'#'localhost' PASSWORD EXPIRE NEVER;
-- quit mysql
quit
# exit back to host shell
exit
vagrant up --provision
How did you set the password? It sounds like in the process, you probably created a new user which didn't have the proper permissions. This explains why you weren't able to see the databases when connecting as that user.
Then, you went and deleted that user, which would have put you back where you started, except you also changed the host from 0.0.0.0 to 'localhost'. I'm not familiar with using the 0.0.0.0 syntax in this location, but presumably it means all TCP hosts just like when used in my.cnf for bind-address. Normally I use '%', but I hesitate to suggest that because if 0.0.0.0 was working, I wouldn't mess with it. But anyway, 'localhost' is different from '%' or any other TCP connection; localhost specifically refers to socket connections, whereas the others refer to TCP connections. Probably your applications are using the tcp protocol, and you just removed permissions for that user (by telling MySQL to only allow connections over the socket protocol).
I suggest any of these solutions:
Revert the existing user to the 0.0.0.0 hostname
Change the existing user's hostname to %
Add a new user, but give proper permissions to the database that user needs to access
Tell your applications to access MySQL using the socket protocol rather than tcp networking (depending on your exact system configuration).
I had this problem for many days and it really drives me crazy. Dont know why, my Homestead and its credential to access to mysql was fine until recently. Basically I just create a new user and stop using homestead as user.
If you can still ssh to it and sudo su, you can try this.
1) vagrant ssh
2) sudo su
3) mysql -u root -p ( when you are as super user, mysql wont ask you password)
4) Then simply set a new user.
CREATE USER 'newuser'#'localhost' IDENTIFIED BY 'password';
then
GRANT ALL PRIVILEGES ON * . * TO 'newuser'#'localhost';
5) Then, login to phpmyadmin using the new user.
I have recently installed MySQL 5.7.16 on an iMac running El Capitan. I had a few minor hiccups initially because I forgot the root password but that has now been reset and I can now log into MySQL as root user using:
$ mysql -u root -p
However, when I try to connect to MySQL server as root using SequelPro, I get the message:
Unable to connect via the socket, or the request timed out.
Double-check that the socket path is correct and that you have the necessary privileges, and that the server is running.
MySQL said: Your password has expired. To log in you must change it using a client that supports expired passwords.
When I look in /tmp folder, I was expecting to find mysql.sock but, instead, there is a file called mysql.sock.lock. Could this be causing the problem? I can't find where that .lock file has come from and I'm not sure what to do about it. Any help would be appreciated.
I'm not entirely sure what happened to cause the root password to expire but something had thrown a spanner in the works. Anyway, the solution for me was to log into MySQL from the Terminal using:
$ mysql -u root -p
...and then alter the root user's password using:
> ALTER USER 'root'#'localhost' IDENTIFIED BY 'NewPass';
That seemed to do the trick. I was then able to log in to MySQL using Sequel Pro with no problems.
Instead of using a socket connection, you could try connecting via Sequel Pro's standard connection using 127.0.0.1 as the host.
Thus spake the 5.7 docs:
The installation process creates only a single root account, 'root'#'localhost', automatically generates a random password for this account, and marks the password expired. The MySQL administrator must connect as root using the random password and assign a new password. (The server writes the random password to the error log.)
So, connect from terminal and change the root password.
Either your first password may not have been saved OR it just truly never persisted.
For me it was the sudo /usr/local/bin/mysql_secure_installation that may not have ever persisted the password correctly. Since your first password never changed, there is no password or ,like your error said, "expired" to nothing.
Run or rerun the code above, don't type anything for the password field and follow the steps, from the preloaded setup program.
I assigned a password to the root MySQL user in XAMPP some times ago. I recently tried to undo that and give it no password but it's not working.
I tried setting the password to an empty string using mysqld --skip-grant-tables and then using the mysql command line directly. It looks like it works, the root user no longer has a password, however if I login in PhpMyAdmin I cannot see any of my databases, only an "information_schema" and a "test" database. If I look at the User tab, it seems to have all the privileges though:
Any suggestion on how to fix this issue?
Note: I checked with the command line, all my databases and tables are still there, I just cannot see them in PHPMyAdmin.
Try removing the anonymous user who is allowed to connect from any host. My feeling is that that row is taking precidence over the row for root when MySQL validates the login.
If you have removed that Anonymous user and the issue still occurs, try setting a password to root and the host to localhost then connect again.