Something is wrong. I stopped MaridaDB, moved /var/lib/mysql to a different place, then replaced the old mysql with a softlink
cd /var/lib
ln -s /data/mysql .
Then I added
chown -R mysql:mysql mysql
and then I went to /data and did the same (Note: this relocation works fine in regular mysql). But in MariaDB
ERROR] mysqld: Can't create/write to file
'/var/lib/mysql/aria_log_control' (Errcode: 13 "Permission denied")
[ERROR] mysqld: Got error 'Can't create file' when trying to use aria
control file '/var/lib/mysql/aria_log_control' [ERROR] Plugin 'Aria'
init function returned error. [ERROR] Plugin 'Aria' registration as a
STORAGE ENGINE failed.
So what can I do to fix this? I tried setting
chmod 777 /var/lib/mysql/aria_log_control
but to no avail.
In my case the problem was that while directory mysql and files within were owned by user mysql, the path has a directory that lacked x bit for the users that are not in the correct group. In other words, user could not move to the target directory because one of the directories in the path did not allow it.
In My case this happened after a change which required OS restart, turned out that SELINUX was in ENFORCE mode and was not allowing MySQL to access the files, used below command to resolve:
sudo getenforce
sudo setenforce 0
Related
I have added secure-file-priv = "" to my nano /etc/my.cnf file for mysql and now I'm not able to remove it.When I remove that line and try to save it, it's asking me to write to a file and the changes are not saved
I tried to uninstall and install mySQL but due to this the server is not able to start.
Error Messages:
my_print_defaults: [ERROR] Found option without preceding group in config file /etc/my.cnf at line 1.
my_print_defaults: [ERROR] Fatal error in defaults handling. Program aborted!
Starting MySQL
.my_print_defaults: [ERROR] Found option without preceding group in config file /etc/my.cnf at line 1.
my_print_defaults: [ERROR] Fatal error in defaults handling. Program aborted!
my_print_defaults: [ERROR] Found option without preceding group in config file /etc/my.cnf at line 1.
my_print_defaults: [ERROR] Fatal error in defaults handling. Program aborted!
Is there any way I can fix this error, I tried a lot but couldn't find any solution
"errors when saving" are often linked to access rights issues.
run ls -l /etc/my.cnf to confirm that this file is owned by root.
in the vast majority of cases, system wide configuration files are owned by root. To edit a root file, you should do it with root privileges, e.g :
sudo nano /etc/my.cnf
(that's probably how you were able to add the config parameter in the first place)
Recently I installed MySQL Workbench 6.2 and used it to create ER diagrams of the MySQL 5.5.41 databases I'm working with on Ubuntu 12.04. Everything worked fine until I restarted Ubuntu and suddenly mysql was no longer running. Running mysqld from the command line results in this:
150216 12:50:37 [ERROR] Can't read from messagefile '/usr/share/mysql/english/errmsg.sys'
150216 12:50:37 [Warning] Can't create test file /var/lib/mysql/euler.lower-test
150216 12:50:37 [Warning] Can't create test file /var/lib/mysql/euler.lower-test
mysqld: Can't change dir to '/var/lib/mysql/' (Errcode: 13)
150216 12:50:37 [ERROR] Aborting
150216 12:50:37 [Note]
The file /usr/share/mysql/english/errmsg.sys exists, owned by root, with permissions 644. The directory /var/lib/mysql exists, owned by mysql, with permissions 700.
I'm guessing that the installation of Workbench changed something (maybe config files) so that mysql is no longer working, but after a fair amount of Internet research, I have not discovered how to solve this problem. Any help will be greatly appreciated.
Seems like file permission problem. Try running mysqld again using sudo
If this doesn't help, maybe you shouldn't be starting it directly via mysqld. Check if the installer package added a service
sudo service --status-all | grep mysql
And if one exist, use it to start mysql, typically:
sudo service mysqld start
Also don't forget to check if mysqld is already running. If so you can't start duplicate process. I know this sound silly but has happened to me before
ps -ef | grep mysqld
I tried everything and whenever i try to start mysql i get this error
140526 18:21:36 InnoDB: Using Linux native AIO
^G/usr/sbin/mysqld: Can't create/write to file '/mysql/ibAlmthH' (Errcode: 13)
I even tried to chnage tmp dir in my.cnf with full write permissions but i still get that error
I tried this post
https://stackoverflow.com/a/16178696
But still same error
what should i do
Refer this, from the stackoverflow question number-2783313 may it help:
Recent Ubuntu Server Editions (such as 10.04) ship with AppArmor and MySQL's profile might be in enforcing mode by default. You can check this by executing sudo aa-status like so:
# sudo aa-status
5 profiles are loaded.
5 profiles are in enforce mode.
/usr/lib/connman/scripts/dhclient-script
/sbin/dhclient3
/usr/sbin/tcpdump
/usr/lib/NetworkManager/nm-dhcp-client.action
/usr/sbin/mysqld
0 profiles are in complain mode.
1 processes have profiles defined.
1 processes are in enforce mode :
/usr/sbin/mysqld (1089)
0 processes are in complain mode.
If mysqld is included in enforce mode, then it is the one probably denying the write. Entries would also be written in /var/log/messages when AppArmor blocks the writes/accesses. What you can do is edit /etc/apparmor.d/usr.sbin.mysqld and add /data/ and /data/* near the bottom like so:
...
/usr/sbin/mysqld {
...
/var/log/mysql/ r,
/var/log/mysql/* rw,
/var/run/mysqld/mysqld.pid w,
/var/run/mysqld/mysqld.sock w,
/data/ r,
/data/* rw,
}
And then make AppArmor reload the profiles.
# sudo /etc/init.d/apparmor reload
WARNING: the change above will allow MySQL to read and write to the /data directory. We hope you've already considered the security implications of this.
Try to run this command manually:
touch /mysql/ibAlmthH
If it failed to create it, you then have a filesystem problem, e.g. read-only filesystem,
So you need to fix the filesystem problem first,
Also check the available disk space on this directory, may be there is no space.
Change directory permission to read, write and execute..
Chmod 777 /directory_path
I'm running on EC2, and want to have MYSQL's datadir on another EBS. I mounted the EBS (ext3) on /data and changed the datadir in my.cnf to point to that dir. However, when I try to start mysql, I get this error:
120518 03:53:17 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
120518 03:53:28 mysqld_safe Starting mysqld daemon with databases from /data/mysql/
120518 3:53:28 [Warning] Can't create test file /data/mysql/ip-10-136-23-225.lower-test
120518 3:53:28 [Warning] Can't create test file /data/mysql/ip-10-136-23-225.lower-test
/usr/libexec/mysqld: Can't change dir to '/data/mysql/' (Errcode: 13)
120518 3:53:28 [ERROR] Aborting
120518 3:53:28 [Note] /usr/libexec/mysqld: Shutdown complete
120518 03:53:28 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
Any ideas?
If you are running on a distro like Ubuntu, then AppArmor is probably blocking mysqld from being able to access files in a different directory. If you check your system log files, you'll find a cryptic error message to this effect.
Solutions include:
Disable AppArmor (not recommended)
Edit the AppArmor rules (complicated)
Use "mount bind" to make MySQL think that your data files are in the original location while they are actually over on the EBS volume. Revert your changes to datadir.
I wrote an article for Amazon years back describing community best practices for exactly what you are trying to do including commands for the mount bind example:
Running MySQL on Amazon EC2 with EBS
http://ec2ebs-mysql.notlong.com
Note that the AMI id in the article is old. Using a modern Ubuntu AMI, you'll need to replace /dev/sdh with /dev/xvdh in the mkfs.xfs and /etc/fstab (but not in the ec2 tools command lines).
If you're running Ubuntu, you can run into this error due to the apparmor service. To get around this. To get around it, you need to do the following:
1) Edit '/etc/apparmor.d/usr.sbin.mysqld' and add these lines:
/opt/lib/mysql/ r,
/opt/lib/mysql/** rwk,
( assuming your new data directory is in /opt/lib/mysql )
2) re-start the apparmor service:
sudo service apparmor restart
Change owner of /data directory to mysqld process owner (chown owner /data ). or (chmod 777 -R /data) very unsafe.
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.