The MariaDB server (5.5.35?) which is preinstalled on my linux system came broken, and instead of trying to fix it (#1 it's out of date, #2 I might break the system in the process since it's pre-installed), I downloaded MySQL 5.7.16 (the .tar.gz version, see #2 for reason). Then I changed the data folder, logs folder, etc. to get away from MariaDB and put them in my own my.cnf file. Also made a symbolic link called '/usr/local/mysql' to my actual MySQL installation in my home folder.

I'm having trouble configuring/running mysqld as mysql user (which came with MariaDB), but it can run well as root (yes, I know the security risks but the server is only for testing).

It seems to have trouble creating some files for writing. The following is from running mysqld with mysql user & personal my.conf:

    2016-12-05T17:22:26.420468Z 0 [ERROR] InnoDB: Cannot open '/home/me/Downloads/mysql-5.7.16-linux-glibc2.5-x86_64/data//ib_buffer_pool' for reading: Permission denied

    miscellaneous failures/server shutdown as a result


    2016-12-05T17:22:26.729869Z 0 [ERROR] InnoDB: Cannot open '/home/me/Downloads/mysql-5.7.16-linux-glibc2.5-x86_64/data//ib_buffer_pool.incomplete' for writing: Permission denied

Initializing the database gives the same error but woth'data/mysql/db.MYI' instead of data/ib_pool.

Here are the file ownerships for mysql (I didn't provide file permissions in case that's irrelevant):

  • All folders except data and mysql-files: My home user
  • data and mysql-files: mysql

Groups are the same as the owners.

Update: changing /usr/local/mysql permissions let me initialize/start the server, but I still can't connect to it on any user (even root@localhost gets Access Denied), when I removed /usr/local/mysql link and redirected all paths to my home dir, problem came back again.

Can someone help me use another user besides root?

2 Answers 2


It looks like permissions for your actual data/* is correct: mysql:mysql, but if you're having it access that through a symlink in your own user's $HOME, then the permissions leading up to the symlink are probably what is blocking mysql from accessing the symlink path.

What about giving mysql its own $HOME, like /home/mysql/{etc,data} (chown mysql:mysql) and place its configuration and data files within that. You could always add your user to the mysql group if you need to access mysql's config or data as your own user.

  • You were right - the symbolic link was causing a few open errors, but not all of them. I still have to initialize as root, and I cannot start server/connect at all. MySQL is literally in it's own 'home', it can access my.cnf and everything. I'm trying to see what it's trying to open with gdb. Commented Dec 6, 2016 at 7:00
  • Your idea of giving mysql a $HOME would've also worked too (there are no permissions to block mysql because the folder is it's). If I had enough rep I'd give your answer +1. Commented Dec 6, 2016 at 12:11
  • Thanks for the feedback, and it looks like you figured it out in the end. Good detailed write up!
    – danarchy85
    Commented Dec 8, 2016 at 19:04

Well, I failed to use gdb, but here's what I found:

  • No group/other permissions in home folder

After configuring my system so I could follow the MySQL manual's instructions step by step, I noticed my home directory doesn't have group/world permissions. Even though I was running mysqld through a symbolic link, I think home folder permissions were preventing it from opening/creating/reading/writing files (though not sure why only some files).

Solution: I moved my MySQL installation to /usr/local/mysql. No symbolic links, no resources in the home folder, nothing. You'll be able to initialize/start the server at this point.

By the way, I just noticed this in the manual (I boldfaced the important part):

After initializing the data directory, you can establish the final installation ownership settings. To leave the installation owned by mysql, no action is required here. Otherwise, most of the MySQL installation can be owned by root if you like. The exception is that the data directory and the mysql-files directory must be owned by mysql.

  • Unidentified password!?!

With the server up, I tried to connect as root, with the (expired) temporary password I got during initialization, fails with 'Access Denied'.

Then I tried connecting without a password, same error.

I even wrote this command in a file (replace 'MyNewPass' with your new password):

ALTER USER 'root'@'localhost' IDENTIFIED BY 'MyNewPass';

and running mysqld like this (with a real path, of course):

# mysqld --init-file=/path/to/mysql-init-command &

which didn't reset the password, either.

Solution: Modify the user table directly by putting this command in a file (again, substitute 'MyNewPass' with your new password):

UPDATE mysql.user
    SET authentication_string = PASSWORD('MyNewPass'), password_expired = 'N'
    WHERE User = 'root' AND Host = 'localhost';

Then restart the server, this time specifying the same initialization command (i.e. with --init-file=/path/to/mysql-init-command). Then log on with your new password. Works like a charm - tested it in MySQL Workbench.

More information about that can be found here.

And that's not all: I figured out my MariaDB package was 'broken' because I don't have the password to log in!, so I have to reset it using the solution above. [So much for 'Securing the initial MySQL Accounts', Oracle. >:( ], but I'm still staying with MySQL because I had a bad history with MariaDB's un-downloadable documentation. There. Killed two birds with one stone.

Bottom line: reset the password before using a preinstalled database server (unless you have the luxury to specify it at install-time like Windows).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.