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.
Related
I've been trying out all solutions mentioned in google for this problem to no avail. This website is built using bitnami wordpress stack in AWS. All I want to do is to log slow query. I only have wp-config user credentials to login in to mysql. But with this access I cannot run SET GLOBAL slow_query_log = 'ON';
as it requires super user privilege.
To my understanding, unless I login as root user and assign the privilege to this user or run the command as root user itself no other workaround to get this sorted.
Problem is, no password for root. Maybe it's configured without password when it was first installed (mysql).
I checked this file for password but found none.
/opt/bitnami/mysql/my.cnf
I can't view the mysql log too (permission denied)
/opt/bitnami/mysql/data/mysqld.log
I dont find the password in aws->instance settings -> get system log
I tried resetting password as mentioned here. https://community.bitnami.com/t/unable-to-reset-mysql-root-password/44360/3
mysql stops but stuck at starting in safe mode forever usin below commands:
$ sudo /opt/bitnami/ctlscript.sh stop mysql
$ sudo /opt/bitnami/mysql/bin/mysqld_safe --skip-grant-tables
How do I enable the slow query log now or get root password or reset it?
Hi Bitnami Engineer here,
The root's password of the database is the same one the instance configures for WordPress during the boot process. That means that if you have not changed the WordPress' admin password, both passwords are the same now.
You can open the bitnami_credentials file in the home folder of the bitnami user to obtain the password the instance used during the configuration process.
cat /home/bitnami/bitnami_credentials
After that, just run the mysql command to access the database
mysql -u root -p
Can anyone tell me why I got an alert with the access denied error?
I tried to create a mysql database and I confidently sure I entered the correct password for root yet I still got this error.
However, based on the mysql documentation for troubleshooting, my error specified that I did not enter the correct password which in fact I did not.
Mysql documentation
https://dev.mysql.com/doc/refman/5.5/en/problems-connecting.html
Also , I tried to run this command sudo mysql -u root -pand it also show me the same error.
P.S Because my reputation is too low, I can't attach the full image.
might be check you are currently connect with the correct password plugin, use the following Command,
SELECT user, authentication_string, plugin, host FROM mysql.user;
If your are login with root, check whether plugin is "mysql_native_password" if not, change as it is with the following command.
ALTER USER 'root'#'localhost IDENTIFIED WITH mysql_native_password BY 'Password#123'
You may get this error when your mysqld is configured to accept connection only from localhost.
In such case, you need to modify bind-address property in /etc/mysql/mysql.conf.d/mysqld.cnf. You can allow only your ip or from the whole internet(0.0.0.0).
Make sure to restart the mysql server.
sudo systemctl restart mysql.
That's not it. You also need to allow connection on port 3306 using commands like ufw or iptables.
I had this problem on Beekeeper and DBeaver. It was driving me INSANE. I literally copied the password and was testing the connections manually and it was working perfectly. Annoyingly this server was working perfectly with MySQL workbench on Windows before I migrated over to Fedora.
So I needed to set the "SSH" section so that it would log me in to the other device. That test connection worked perfectly. But STILL no success. "Password failure" an incredibly inaccurate error message...
Turns out after enabling the SSH connection I forgot to change the "Server host" variable from it's IP (192...) to 'localhost'. Now it works perfectly.
It Could be various things try this:
In main configuration username="root" password="YOUR_PASSWORD" As in no need to put the actual password, only copy "YOUR_PASSWORD"
If it still doesn´t work leave the database bank
Check that your IP address is added to the server permissions/security
Check that the DB is available and that public connection is allowed
If using Windows allow connections to the port 3306 on the Firewall Defender(control panel, security, firewall defender, advanced setting, add inbound rule, port, 3306, allow)
For anyone struggling with SSH tunnel. I found that sometimes 127.0.0.1 is not being translated back to localhost before privileges are being check.
Try setting up a grant for 127.0.0.1 with the following.
GRANT ALL PRIVILEGES ON *.* TO 'user'#`127.0.0.1`;
This did the trick for me.
Please enter these configurations in connection window
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 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.
Current situation is as follows:
I have succesfully installed OpenProject on Ubuntu 14.04 server using the guide from the official website (https://www.openproject.org/open-source/download/packaged-installation-guide/). When configuring for the first time I let the configuration manager install MySQL and create the appropriate database(s).
Now I'm trying to migrate and for this to happen, I need outside access to the information_schema (schema) and database. This is supposedly done using the openproject user but I cannot seem to be able to login using this user on the commandline.
Just to be sure, I just statement below:
mysql -u openproject -D openproject -p
Then I entered the right password and press enter. It gets the default ERROR 1045.
I am however able to login using root user and debian-sys-maint user which was created on the initial install step. The password I used for these accounts were found in the file under "/etc/openproject/installer.dat". I am absolutely positive I use the correct password, for the application runs fine under said user.
Is there a setting in mysql that I am missing that would block users from making connection using the commandline utility?
Figured it out. In MySQL the host 127.0.0.1 and localhost are essentially different. User OpenProject by default gets assigned to host 127.0.0.1, so naturally connecting openproject#localhost did not work, though root account has different user profiles (4 to be exact) allowing it to connect to both localhost and 127.0.0.1 .
TLDR version:
Use the statement as follows:
mysql -u openproject -h 127.0.0.1 -p
Should do the trick.