I'm new to the Docker world and I'm trying to achieve something one could think is trivial. However, it seems a lot of beginners struggle to persist their data when using Docker.
I've built a custom image using a Dockerfile. The container runs a MySQL server and... yes, you guessed it: I'd like to persist the data.
Here is my Dockerfile:
FROM debian:8.7
ENV MYSQL_ROOT_PASSWORD=test
RUN apt-get update -y && apt-get install -y apt-utils && \
echo "mysql-server mysql-server/root_password password $MYSQL_ROOT_PASSWORD" | debconf-set-selections && \
echo "mysql-server mysql-server/root_password_again password $MYSQL_ROOT_PASSWORD" | debconf-set-selections && \
apt-get install -y mysql-server mysql-client && service mysql start
CMD service mysql start && /bin/bash
VOLUME /var/lib/mysql
EXPOSE 3306
I build and run the image this way:
docker build -t mysql-persist-test:0.1 .
docker run -dt -v database_volume:/var/lib/mysql mysql-persist-test:0.1
So far, everything works as expected, including the database.
However, let's say I want to retrieve the data on my host machine (Windows 10, I installed Docker via the Docker Toolbox).
I "bind" a local folder to the named volume with Kitematic (see below), the container automatically restarts and... everything is broken! All the files in the /var/lib/mysql directory were removed. Some were re-created with the owner staff instead of mysql.
Then I have these errors in /var/log/mysql/error.log:
...
/usr/sbin/mysqld: Table 'mysql.plugin' doesn't exist
170328 16:03:13 [ERROR] Can't open the mysql.plugin table. Please run mysql_upgrade to create it.
...
170328 16:03:13 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
...
170328 16:03:13 InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
InnoDB: Apply batch completed
...
170328 16:03:14 [ERROR] Fatal error: Can't open and lock privilege tables: Table 'mysql.host' doesn't exist
What am I doing wrong?
The volume hierarchy
Data in containers is in sort of a hierarchy. It goes like this.
1. part of the image
This is the lowest level, where data is in the read-only, immutable image itself.
2. in the read-write layer
Once you start a container from an image, a read-write layer is added on top of the existing image layers. If anything is changed, added, or removed in the container, by default it is written here.
Changes in this layer over-ride data in layer 1.
3. Docker volumes
In your example, you have created a volume in Docker, with
VOLUME /var/lib/mysql
This will create a volume within Docker, that can be re-used, persisted, shared among containers, etc. If there was anything at /var/lib/mysql in layer 1, then the contents of this volume override. If you make changes in the container, they are made in the volume (skipping over layer 2).
4. External volumes
Finally, we have external directories that you can mount inside the container. This overrides all the others.
Since they are based on an external directory, any changes made in the container will be easily accessed from outside. That's presumably why you tried this approach.
What happened to you
You started with a Docker volume (level 3) and then changed to an external volume (level 4). Since level 4 overrides level 3, what happens is the contents of your external directory (probably no contents), override the Docker volume. Therefore the container just sees an empty directory.
Your files are still there. Just undo the external mount and go back to the Docker volume; they'll be waiting there.
How to get your files out
EDIT: as Carlos points out in comments, docker cp is simpler, editing to use that approach instead.
docker cp <container-id>:/var/lib/mysql ./mydata
This will copy the contents of /var/lib/mysql into the folder mydata.
Related
I'm at my wit's end with this, so hopefully you folks can help me. In OSX 10.11.2 with docker-machine, I've got a docker-compose file that should build a local Dockerfile and attach a MySQL container to it. The MySQL container should mount a local folder where I'm storing my database data, so if the container or VM comes down, I can just restart it without data loss. Problem is, when I run it, it throws a permissions error:
db_1 | 2015-12-23 19:17:59 7facaa89b740 InnoDB: Operating system error number 13 in a file operation.
db_1 | InnoDB: The error means mysqld does not have the access rights to
db_1 | InnoDB: the directory.
I've tried every permutation I can think of to get this to work. I was reading around and it may have something to do with how docker-machine handles permissions with OSX, but the documentation for docker-machine says that it mounts the /Users folder, so that shouldn't be an issue.
Here's the docker-compose.yml:
web:
build: .
ports:
- "3000:3000"
links:
- db
db:
image: mysql:5.6
ports:
- "3306:3306"
volumes:
- /Users/me/Development/mysql-data:/var/lib/mysql
environment:
MYSQL_ROOT_PASSWORD: mypass
Any ideas? I can't help but think it's something really simple. Any help would be most appreciated!
Edit:
Host - drwxr-xr-x 7 me staff 238 Dec 23 12:10 mysql-data/
VM - drwxr-xr-x 1 docker staff 238 Dec 23 20:10 mysql-data/
As to the container, it won't run with the volume mounted. Without the -v mount, it is:
Container - drwxr-xr-x 4 mysql mysql 4096 Dec 24 00:37 mysql
The issue this comes from is the userids used by Mac and Linux respectively. Mac does not like Linux wanting to use the 1 for the userID.
The way I worked around all the permissions craziness in my mac + docker-machine setup is to use this Dockerfile
FROM mysql:5.6
RUN usermod -u 1000 mysql
RUN mkdir -p /var/run/mysqld
RUN chmod -R 777 /var/run/mysqld
Instead of the plain MySQL 5.6 Image.
The last 2 lines are necessary, because changing the userid for the mysql user will mess up the build in permissions for that image. => you need the 777 permissions to make it run here :/
I know this is a little hacky, but so far the best solution I know to the permissions issue here.
Try to use the latest docker for mac instead of docker tools. Docker for Mac no longer uses VirtualBox, but rather HyperKit, a lightweight OS X virtualization solution built on top of Hypervisor.framework in OS X 10.10 Yosemite and higher.
I suggest also completely remove docker tools(they could co-exist): https://github.com/docker/toolbox/blob/master/osx/uninstall.sh
With docker for mac, you don't have to use permission hacks, it would just work like it would be on a linux build.
I'm trying to debug a page in a web app that keeps crashing Chrome ("Aw, snap!" error). I've enabled/disabled automatic crash reporting, tried logging with google-chrome --enable-logging --v=1, (as well as various levels of verbosity), and all I get is a "crash dump ID" in the chrome_debug.log chrome://crashes Shows all of the dump IDs, but no actual dump file
I see other questions referring to reading the dump files, but I can't find the dump files themselves (just the ID).
Grepping for the crash ID in /tmp and ~/.config/google-chrome/ turns up nothing, but the ~/.config/google-chrome/chrome_debug.log shows that something was sent:
--2015-04-06 11:10:00-- https://clients2.google.com/cr/report
Resolving clients2.google.com (clients2.google.com)... 74.125.228.224, 74.125.228.225, 74.125.228.231, ...
Connecting to clients2.google.com (clients2.google.com)|74.125.228.224|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: ‘/dev/fd/3’
0K
Crash dump id: 7dac9d5d58258264
Any ideas on where to find the actual file/data that's sent?
Details:
Chrome version: 40.0.2214.111 (Official Build)
Linux Mint 16 (Petra)
Edit: Some extra info:
curtis#localhost:-$ tail -n 5 uploads.log && echo $(pwd)
1428584493,ddc357e4600a49e6
1428584497,7ac16455c152381a
1428589439,d00ad6f5e6426f3d
1428934450,66b3f722430511e8
1428939578,7a2efc2b681515d1
/home/curtis/.config/google-chrome/Crash Reports
curtis#localhost:-$ ll -a
total 12
drwx------ 2 curtis curtis 4096 Apr 6 11:32 .
drwx------ 9 curtis curtis 4096 Apr 13 11:43 ..
-rw------- 1 curtis curtis 3291 Apr 13 11:39 uploads.log
Automatic reporting is enabled...
Thanks!
The *.dmp files are stored in /tmp/, and this has nothing to do with the "Automatic crash reporting" checkbox. The file is also not related to the hash stored in ~/.config/google-chrome/
In ~/.config/google-chrome/Crash Reports/uploads.log:
1429189585,5bddea9f7433e3da
From using , the crash dump file for this particular report was:
chromium-renderer-minidump-2113a256de381bce.dmp
Solution:
root#localhost:-$ mkdir /tmp/misc && chmod 777 /tmp/misc
root#localhost:-$ cd /tmp
root#localhost:-$ watch -n 1 'find . -mmin -1 -exec cp {} /tmp/misc/ \;'
Then, as a regular user (not root):
google-chrome --enable-logging --v=1
Once you see files created by the watch command, run:
root#localhost:-$ ls -l
-rw------- 1 root root 230432 Apr 16 09:06 chromium-renderer-minidump-2113a256de381bce.dmp
-rw------- 1 root root 230264 Apr 16 09:12 chromium-renderer-minidump-95889ebac3d8ac81.dmp
-rw------- 1 root root 231264 Apr 16 09:13 chromium-renderer-minidump-da0752adcba4e7ca.dmp
-rw------- 1 root root 236246 Apr 16 09:12 chromium-upload-56dc27ccc3570a10
-rw------- 1 root root 237247 Apr 16 09:13 chromium-upload-5cebb028232dd944
Now you can use breakpad to work on the *.dmp files.
Google Chrome - Crash Dump Location
To generate the Crash Dump locally,
CHROME_HEADLESS=1 google-chrome
The .dmp files are then stored in ~/.config/google-chrome/Crash Reports
Produce Stack Trace
Check out and add depot_tools to your PATH (used to build breakpad)
git clone https://chromium.googlesource.com/chromium/tools/depot_tools
export PATH=`pwd`/depot_tools:"$PATH"
Check out and build breakpad (using fetch from depot_tools)
mkdir breakpad && cd breakpad
fetch breakpad
cd src
./config && make
To produce stack trace without symbols:
breakpad/src/processor/minidump_stackwalk -m /path/to/minidump
More here https://www.chromium.org/developers/decoding-crash-dumps
Personally Preferred Method
Enable crash reporting:
Chrome menu > Settings > Show advanced settings > Tick "Automatically send usage statistics and crash reports to Google"
Go to chrome://crashes > File bug > Takes you to crbug.com > Complete
report leaving the auto-added report_id field unchanged.
Someone from the Chrome/Chromium team will follow up. They can provide
you with your stack trace and aid at resolving the issue.
Trying to back out of a macports mysql installation and return to Snow Leopard Server's built-in MySQL server, but I cannot get it to work.
When I disable macports and enable the built-in service, mysql.sock cannot be found (locate mysql.sock returns nothing). When I re-enable the macport mysql, mysql.sock is found but now I cannot disable the built-in MySQL service.
Every time I try, it just re-enables it.
I have to run the following commands to get MacPorts MySQL to work upon reboots:
sudo launchctl unload -w /Library/LaunchDaemons/org.macports.mysql5.plist
sudo launchctl load -w /Library/LaunchDaemons/org.macports.mysql5.plist
ln -s /var/mysql/mysql.sock /tmp/mysql.sock
Permissions on /var/mysql are (which is where the built-in service is set to):
drwxr-xr-x 111 _mysql _mysql
Permissions on the macports datadir are:
drwxr-xr-x 116 _mysql _mysql
At one time, according to the access log file for the built-in mysql, it started up correctly (2010). Is there a way to manually disable this service from starting up when I reboot?
I realize how unclear my problem is, but somehow the previous admin got macports mysql tied in with the built-in mysql and I'm having a heck of a time untangling them.
In /Library/LaunchDaemons/ plist-files of the installed applications are located, here's what I have there:
$ ls -l /Library/LaunchDaemons/
-r--r--r-- 1 root wheel 573 Jan 10 18:33 at.obdev.littlesnitchd.plist
-rw-r--r-- 1 root wheel 567 Mar 5 19:02 com.parallels.desktop.launchdaemon.plist
lrwxr-xr-x 1 root admin 74 Jan 20 06:21 org.macports.mysql5.plist -> /opt/local/etc/LaunchDaemons/org.macports.mysql5/org.macports.mysql5.plist
lrwxr-xr-x 1 root admin 74 Oct 14 2011 org.macports.rsyncd.plist -> /opt/local/etc/LaunchDaemons/org.macports.rsyncd/org.macports.rsyncd.plist
And if you'd like to check the MacOS bundled services' config, take a look at /System/Library/LaunchDaemons/.
I've installed MySQL on my personal/development machine using the .dmg package, according to the instructions here: http://dev.mysql.com/doc/refman/5.5/en/macosx-installation-pkg.html including installing the startup item and the preferences pane. And yet, I can't seem to use MySQL at all.
running:
/Library/StartupItems/MySQLCOM/MySQLCOM start
or
/Library/StartupItems/MySQLCOM/MySQLCOM restart
"appears" to work -- in that, it gives me a message like "Starting MySQL database server" -- but afterward, I still can't go into mysql at the command-line, or connect to it in a Rails 2.3.8 application running in script/server. I get the error denoted in the question title.
Also, the MySQL preferences pane doesn't seem to work either. If I click the "Start MySQL Server" button, I'm asked for my password, but then nothing happens -- the pane continues to say that the server is stopped.
(I believe I had a MacPorts version of MySQL installed previously, and it's also possible that there was one built from source at some time in the past -- but I'm reasonably sure I've uninstalled these and deleted all the files having to do with it that I could find.)
I'm also trying mysqld start in terminal. here's the output:
110127 15:40:28 [Warning] Can't create test file /usr/local/mysql-5.5.8-osx10.6-x86_64/data/Lucky-Charm.lower-test
110127 15:40:28 [Warning] Can't create test file /usr/local/mysql-5.5.8-osx10.6-x86_64/data/Lucky-Charm.lower-test
110127 15:40:28 [Note] Plugin 'FEDERATED' is disabled.
mysqld: Can't find file: './mysql/plugin.frm' (errno: 13)
110127 15:40:28 [ERROR] Can't open the mysql.plugin table. Please run mysql_upgrade to create it.
InnoDB: The InnoDB memory heap is disabled
InnoDB: Mutexes and rw_locks use GCC atomic builtins
InnoDB: Compressed tables use zlib 1.2.3
110127 15:40:28 InnoDB: Initializing buffer pool, size = 128.0M
110127 15:40:28 InnoDB: Completed initialization of buffer pool
110127 15:40:28 InnoDB: Operating system error number 13 in a file operation.
InnoDB: The error means mysqld does not have the access rights to
InnoDB: the directory.
InnoDB: File name ./ibdata1
InnoDB: File operation call: 'open'.
InnoDB: Cannot continue operation.
Tried following the message about running mysql_upgrade but that just gives me my original error again.
UPDATE:
OK I've been pursuing the theory that it's a permissions problem. Seeing that the datadir was owned by root, I chown -R it to _mysql. In response to Mike, here's where that now stands:
$ ls -al /usr/local/mysql-5.5.8-osx10.6-x86_64
total 296
drwxr-xr-x 16 root wheel 544 Dec 3 12:53 .
drwxrwxr-x 12 root staff 408 Jan 27 14:38 ..
-rw-r--r-- 1 root wheel 17987 Dec 3 11:58 COPYING
-rw-r--r-- 1 root wheel 12388 Dec 3 11:58 INSTALL-BINARY
-rw-r--r-- 1 root wheel 113534 Dec 3 11:58 README
drwxr-xr-x 44 root wheel 1496 Dec 3 12:53 bin
drwxr-xr-x 9 _mysql wheel 306 Jan 27 16:46 data
drwxr-xr-x 4 root wheel 136 Dec 3 12:53 docs
drwxr-xr-x 47 root wheel 1598 Dec 3 12:53 include
drwxr-xr-x 12 root wheel 408 Jan 27 14:38 lib
drwxr-xr-x 4 root wheel 136 Dec 3 12:53 man
drwxr-xr-x 19 root wheel 646 Jan 27 14:38 mysql-test
drwxr-xr-x 3 root wheel 102 Dec 3 12:53 scripts
drwxr-xr-x 32 root wheel 1088 Dec 3 12:53 share
drwxr-xr-x 28 root wheel 952 Dec 3 12:53 sql-bench
drwxr-xr-x 16 root wheel 544 Dec 3 12:53 support-files
I was trying to do mysqld start in the Terminal because it was the only thing giving me anything that seemed like meaningful error message output (see https://gist.github.com/799436) but I'm told by folks in #mysql that that's not intended to be run directly (and if I try sudo mysqld start i get a message bitching me out for trying to run mysql as root).
I seem to have something working now: mysqld_safe & successfully gets a MySQL server running. What still doesn't work is the "normal" method of starting up the server (the Startup Item or Preferences Pane)
... leading someone in #mysql to tell me that apparently MySQL is fine, it's the startup item that's borked.
Ok there were several things, mostly having to do with permissions/ownership, that were tried to make the binary-installed MySQL work nicely.
You may need to make sure that the startup item is owned by root:
sudo chown -R root:wheel /Library/StartupItems/MySQLCOM
Maybe you need a /etc/my.cnf file with this in it:
[mysqld]
socket=/tmp/mysql.sock
datadir=/usr/local/mysql/data
You might need to fill in these variables in /usr/local/mysql/support-files/mysql.server (the line will be there with blank values):
basedir=/usr/local/mysql
datadir=/usr/local/mysql/data
(see can't start MySql in Mac OS 10.6 Snow Leopard regarding the above)
That may be enough to do it, but if not, try making sure the mysql user (_mysql) can write to the data directory (owns it and has write permissions to everything in it).
Anyway, now the Preferences Panel and Startup Item actually seem to work for me.
After going over this a second time on another machine, I've made some edits and removed some unnecessary bit from what I answered yesterday.
Overall here's what I suggest you do to get the binary-installed MySQL working nice in OSX 10.6. Warning, you might end up deleting any databases you already had in the first couple steps, but as this is intended to be for your development machine, that shouldn't be any big deal. Back stuff up with mysqldump first if you must.
Make sure you don't have a mysql server running right now: ps aux | grep mysql will show you their processes. Stop it with mysqladmin shutdown or if that won't work because something is borked, sudo kill the process numbers.
Remove any prior installed versions of mysql -- check port list installed, check for a homebrew-installed one, sudo find / -name mysql looking for compiled-from-source ones and delete them, whatever it takes. You could even remove the startup item by deleting the /Library/StartupItems/MySQLCOM directory if you want.
Run the mysql-whatever-version.pkg install package
Test it by typing sudo mysqld_safe & at the terminal. If you get "command not found," add /usr/local/mysql/bin to your path and try again. If you get any scary error messages, check for a /etc/my.cnf file as described above and try again. If it still doesn't work, then maybe try recursively chowning and chmoding the /usr/local/mysql/data directory to make sure _mysql can write to it. Once you get it to appear to start up OK, enter mysql at terminal. If you get a MySQL command prompt, all is well (enter exit to get out of it) -- in fact, if you get anything other than the ol' "Can't connect to local MySQL server through socket" then you can conclude that the MySQL server works -- shut down or kill the server and move on.
Next we'll install the startup item. Run MySQLStartupItem.pkg
Test the startup item at the terminal by entering sudo /Library/StartupItems/MySQLCOM/MySQLCOM start. It will give you a message claiming that it is starting up the server, but if it's unsuccessful it won't give you any indication, so try going into mysql again to test that the server is running. If so, enter sudo /Library/StartupItems/MySQLCOM/MySQLCOM stop to stop the server (and to test that the startup item can stop the server as well as start it :D) If it didn't work, try making the settings described above in /usr/local/mysql/support-files/mysql.server. If that still doesn't do it, try the bit up at the top about sudo chown -R root:wheel /Library/StartupItems/MySQLCOM.
Once that works, run/install the MySQL.prefPane. This should give you a MySQL item in your System Preferences near the bottom, and if you go in there, you should see a button that you can click which will stop/start the MySQL server. Try it, and if it doesn't work by now, I'm not sure what else I can tell you.
I had experienced the same error after removing my old mac ports and installing mysql in a new mac ports directory ( a new /opt/local ).
I fixed it by setting the correct permissions for the mysql directories in the ports tree:
chown -R _mysql:_mysql /opt/local/var/db/mysql5
chown -R _mysql:_mysql /opt/local/var/run/mysql5/
chmod -R 755 /opt/local/var/run/mysql5
I'm not sure if the chmod was needed. Of course ports had already done the job of creating the _mysql user and group.
Server shutdown from power failure.
Mysql will not start now.
Disk is not full.
Syslog is below
Oct 11 15:03:31 joe mysqld_safe[24757]: started
Oct 11 15:03:31 joe mysqld[24760]: 101011 15:03:31 InnoDB: Operating system error number 13 in a file operation.
Oct 11 15:03:31 joe mysqld[24760]: InnoDB: The error means mysqld does not have the access rights to
Oct 11 15:03:31 joe mysqld[24760]: InnoDB: the directory.
Oct 11 15:03:31 joe mysqld[24760]: InnoDB: File name ./ibdata1
Oct 11 15:03:31 joe mysqld[24760]: InnoDB: File operation call: 'create'.
Oct 11 15:03:31 joe mysqld[24760]: InnoDB: Cannot continue operation.
If you are using ubuntu or apparmor you should permit this change in apparmor.
Edit /etc/apparmor.d/usr.sbin.mysqld and change /var/lib/mysql with the new DATADIR.
It should work.
Error:
101130 14:42:51 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
101130 18:07:58 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
101130 18:07:58 InnoDB: Operating system error number 13 in a file operation.
InnoDB: The error means mysqld does not have the access rights to
InnoDB: the directory.
InnoDB: File name ./ibdata1
InnoDB: File operation call: 'open'.
InnoDB: Cannot continue operation.
Solution SeLinux SeLinux security:
[root#localhost ~]# service mysqld restart
Deteniendo mysqld: [ OK ]
Iniciando mysqld: [ FALLÓ ]
[root#localhost ~]# restorecon -R /var/lib/mysql/
[root#localhost ~]# service mysqld restart
Deteniendo mysqld: [ OK ]
Iniciando mysqld: [ OK ]
[root#localhost ~]#
please check this:
chown -R mysql:mysql /var/lib/mysql
The file is not corrupt. You can find out the source of these errors with 'perror'. i.e.
toaster:~ morgo$ perror 13
OS error code 13: Permission denied
InnoDB has corruption detection (page checksums) and would happily tell you if that were the problem.
Either the directory permissions have changed, or your my.cnf file has been hosed, and it's trying to recreate data files somewhere else.
For me, restoring the security context (selinux) did the trick
restorecon -R /var/lib/mysql/
In short, (especially on RHEL/CentOS/Fedora) try
getenforce
if it replies with Enforcing you have SELinux up and running. Temporarily deactivate it with setenforce 0 and see if MariaDB starts now! Rather common, especially on RHEL/CentOS/Fedora.
There's more about this further down, as well as in this official article.
In general
There are more things in a UNIX environment that might prevent file access, than just user access rights.
Security modules like SELinux (see above) or AppArmor (as Dan mentioned) could disallow it
Access Control Lists (ACL) could be specifically set, for the required files/directories
Any of the parent folders could be owned by another user, and have no x (="dir access") set for others
Additionally there could be other unexpected factors, like ...
The mysql datadir being set to a place, where mysql doesn't have permissions (see /etc/my.cnf)
Mysql could (strangely) be running as a different user, or the file could be simply owned by someone else
Just to mention a view things off the top of my head (feel free to edit/add to this answer btw).
In the case, SELinux is "the problem"
For a permanent solution, you could try to restore the appropriate security context, ...
restorecon -R /var/lib/mysql/
... or just deactivate SELinux (but think about this one a little bit before doing so), by editing the config (typically in /etc/selinux/config) and setting SELINUX=disabled as suggested in following article.
Here the official help page from mariadb.com: What to do if MariaDB doesn't start
And here something from redhat.com: MariaDB Changing Database Location
Obviously those are applicable to MySQL just the same way.
I had exactly the same problem on my CentOS box. After moving mysql data directory around I couldn't start the service anymore, even as I had copied the files with the same owner and permissions.
I had a problem with the SELinux security context. If you run your CentOS stock it has good chance to be enabled and won't let do what you want with MySQL. To fix this :
First compare the old dir and new dir using
ls -Z /var/lib/mysql
and
ls -Z /new/mysql/dir
If you see any difference it's likely to be your problem.
To modify this :
chcon -R --type=mysql_db_t /new/mysql/dir
The -R switch is for recursion. If you only need to change one file you can omit it.
If your context is different than mine(maybe a different distro), use the one indicated by the output of the first (it should be the 3rd field of the SELinux stuff)
ls -Z /var/lib/mysql
I had the same problem and fix by below steps
Working directory /var/lib/mysql
Earlier /var/lib/mysql was owned by some unknown user
Changed it to mysql
mysql]# chown -R mysql:mysql *
mysql]# service mariadb start
Redirecting to /bin/systemctl start mariadb.service
Works like a charm
I had exactly the same problem on my CentOS box. After moving mysql data directory around I couldn't start the service anymore, even as I had copied the files with the same owner and permissions.
I had a problem with the SELinux security context. If you run your CentOS stock it has good chance to be enabled and won't let do what you want with MySQL. To fix this :
First compare the old dir and new dir using
ls -Z /var/lib/mysql
and
ls -Z /new/mysql/dir
If you see any difference it's likely to be your problem.
To modify this :
chcon -R --type=mysql_db_t /new/mysql/dir
The -R switch is for recursion. If you only need to change one file you can omit it.
When this popped up for me, I found the answer in the /etc/mysql/my.cnf configuration file. The datadir line did not point to the /var/lib/mysql directory (where the databases are). Once I put this path in, the server restarted no problem.
If you use SEL Linux
Intall semanage
yum whatprovides /usr/sbin/semanage you get policycoreutils-python-2.5-22.el7.x86_64
See mysqld security context
After installation yum install policycoreutils-python you can just look what different security context mysqld has.
semanage fcontext -l | grep mysqld
/etc/mysql(/.*)? all files system_u:object_r:mysqld_etc_t:s0
/etc/my\.cnf\.d(/.*)? all files system_u:object_r:mysqld_etc_t:s0
/var/log/mysql.* regular file system_u:object_r:mysqld_log_t:s0
/var/lib/mysql(-files|-keyring)?(/.*)? all files system_u:object_r:mysqld_db_t:s0
/var/run/mysqld(/.*)? all files system_u:object_r:mysqld_var_run_t:s0
/var/log/mariadb(/.*)? all file system_u:object_r:mysqld_log_t:s0
/var/run/mariadb(/.*)? all files system_u:object_r:mysqld_var_run_t:s0
/usr/sbin/mysqld(-max)? regular file system_u:object_r:mysqld_exec_t:s0
/var/run/mysqld/mysqlmanager.* regular file system_u:object_r:mysqlmanagerd_var_run_t:s0
/usr/lib/systemd/system/mysqld.* regular file system_u:object_r:mysqld_unit_file_t:s0
/usr/lib/systemd/system/mariadb.* regular file system_u:object_r:mysqld_unit_file_t:s0
/etc/my\.cnf regular file system_u:object_r:mysqld_etc_t:s0
/root/\.my\.cnf regular file system_u:object_r:mysqld_home_t:s0
/usr/sbin/ndbd regular file system_u:object_r:mysqld_exec_t:s0
/usr/libexec/mysqld regular file system_u:object_r:mysqld_exec_t:s0
/usr/bin/mysqld_safe regular file system_u:object_r:mysqld_safe_exec_t:s0
/usr/bin/mysql_upgrade regular file system_u:object_r:mysqld_exec_t:s0
/etc/rc\.d/init\.d/mysqld regular file system_u:object_r:mysqld_initrc_exec_t:s0
/var/lib/mysql/mysql\.sock socket system_u:object_r:mysqld_var_run_t:s0
/usr/libexec/mysqld_safe-scl-helper regular file system_u:object_r:mysqld_safe_exec_t:s0
/home/[^/]+/\.my\.cnf regular file unconfined_u:object_r:mysqld_home_t:s0
Here you see all context for mysqld a short list with explanation
mysqld_etc_t - config files
mysqld_db_t - data db files
mysqld_log_t - log files
mysqld_exec_t - execution files
So if you have the wrong security context on your files you get a permission denied (error 13)
Solution
chcon -R -u system_u -t mysqld_db_t /var/lib/mysql
But check the "normal" permissions, too. I had this problem with centos. You have to systemctl restart mysql for the changes.
In my siuation is Selinux's problem. And the
chcon -R --type=mysql_db_t /new/mysql/dir comes error:
chcon: failed to change context of /new/mysql/dir to root:object_r:mysql_db_t: Invalid argument.
So i use the command:chcon -R root:object_r:mysqld_db_t /new/mysql/dir.
If you have this problem on a Synology NAS you can fix it by following the advice of the Synology support team:
Dear User,
This has been confirmed as a known issue and we will try to fix this issue in further MariaDB release. Sorry for your inconvenience.
Here is the workaround:
Please try to telnet to your DS with "root" account and password (same as admin's)
run the command "echo 1 > /var/services/mysql/VERSION"
open MariaDB package from DSM will trigger update again
type in the DB password and click Update will fix this issue
More info: Synology forum
I had the same problem.
Did alot of research and found out this solution.
You need to run this command on ibdata1
sudo shadowprotect -u root | root
I dont know what this does.. but it worked for me.
Good luck.