Accessing UCSC mysql DB: ERROR 1045 (28000): Access denied for user 'genome'
1
1
Entering edit mode
5.9 years ago
kynnjo ▴ 40

This is a follow-up to an earlier question of mine.

I tried the following command (copied verbatim from UCSC's mysql access docs):

mysql --user=genome --host=genome-mysql.cse.ucsc.edu -A

...but it fails with the error message:

What else must I do to get through?

Thanks!

genome • 2.0k views
1
Entering edit mode

If you are connecting to a local UCSC browser instance ("my.host.redacted"), then you may need to change the username and add a password option, depending on the setup of your local browser instance. Check with whoever administrates that server, in that case.

0
Entering edit mode

Thanks for your comment, although now I'm really confused. I don't understand why you say that I'm connecting to my.host.redacted. I thought I was connecting to genome-mysql.cse.ucsc.edu, as the command line says, from my.host.redacted. Also, assuming that there is indeed a "local UCSC browser instance," I would love to use it, but I can't figure out how to refer to it, so that I can connect to it or search for it online.

1
Entering edit mode

Here is the result I get:

\$ mysql --user=genome --host=genome-mysql.cse.ucsc.edu -A
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 6262854
Server version: 5.6.26-log MySQL Community Server (GPL)

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql>


I am able to run commands like show databases; use hg19; and show tables; etc.

Maybe run mysql --version and see if it needs updating.

1
Entering edit mode
5.9 years ago
kynnjo ▴ 40

OK, problem solved.

Diagnosis: PEBKAC [1]

(one) Solution: change the command line to

mysql **--no-defaults** --user=genome --host=genome-mysql.cse.ucsc.edu -A


[1] More specifically: I had a long-forgotten ~/.my.cnf file lingering around, which was required by a pipeline that I used briefly back in 2006; even adding --verbose to the command line did not reveal that an incorrect connection parameter, namely a password, was being read from this file; I knew, from the remark "(using password: YES)" in the error message, that a password was somehow being used, but I had no way of determining the source of this password, nor what it was. How I finally figured out the problem is a tl;dr-length saga I won't bore you with.