Can’t create/write to file ‘/mnt/temp/something’ (Errcode: 13)

amazon ec2amazon-ebsmysql5.5tmpubuntu-12.04

I changed the tmp directory of the mysql configuration to a mounted disk and on service mysql restart I get following error:

Can't create/write to file '/mnt/temp/something' (Errcode: 13)

To my understanding, Error Code 13 refers to file permission error.

But strange part is:

temp directory owner is already mysql and file permission is 1777

drwxrwxrwt 2 mysql mysql 4.0K Nov 14 08:34 temp/
I am able create file in the location with a non root user.
There is 600 Gb of space on mnt so that should not be an issue.
I can create tmp directory easily on root disk

/etc/mysql/my.cnf:

user            = mysql
pid-file        = /var/run/mysqld/mysqld.pid
socket          = /var/run/mysqld/mysqld.sock
port            = 3306
basedir         = /usr
datadir         = /mnt/mysql
tmpdir          = /mnt/temp
#tmpdir         = /var/tmp

Is creating a tmp directory on a mounted disk not allowed? Or else what am I doing wrong? Pls help.

Best Answer

So this is a little old, but I just solved a similar problem, myself (Using /mnt/tmp as the system temp dir) and had to figure out why MySQL wouldn't start up.

You're probably running up against the AppArmor settings that prevent MySQL from using directories on the /mnt drive. You'll need to add your new tmp path to the MySQL app armor list of allowed paths.

If you look in your syslog, you'll probably see messages looking something like this every time you try to start the mysql server:

type=1400 audit(1425343954.203:23): apparmor="DENIED" operation="mknod" parent=1 profile="/usr/sbin/mysqld" name="/mnt/tmp/ibMXP5lg" pid=16418 comm="mysqld" requested_mask="c" denied_mask="c" fsuid=106 ouid=106

In this case, You'll need to edit the file:

/etc/apparmor.d/usr.sbin.mysqld

And add the lines:

/mnt/tmp/ r,
/mnt/tmp/** rwk,

to the file. Then just restart AppArmor:

$ sudo service apparmor restart

Related Solutions

Mysql – Percona MySQL 5.5 fails to start

This question is a bit old now, but in case other people come across this page (like I did), here is what got me working:

In my case the answer was apparmor.

The solution: edit the file /etc/apparmor.d/usr.sbin.mysqld

Add the following lines:

/path/to/new/data/ r,
/path/to/new/data/** rwk,
/path/to/new/logs/ r,
/path/to/new/logs/ rw,

Then restart apparmor:

sudo /etc/init.d/apparmor restart

AppArmor is preventing mysql from accessing the new locations for these files. This is why the permissions all look correct. It is correct that "something" is preventing mysql from accessing the new locations. That "something" is "apparmor" :-)

Apparmor seems to be standard on Ubuntu 11.10, which is where I had this problem. 10.04 does not seem to have Apparmor installed by default.

Hope this helps someone, I've been tearing my hair out over this one for too many hours!

EC2 – AWS SDK – config.inc.php where

Installing the SDK via PEAR places the files in /usr/share/pear/AWSSDKforPHP; config-sample.inc.php is under this folder.

If you look at php -i | grep include_path (or the output of phpinfo()) you should find something like the following: .:/usr/share/pear:/usr/share/php

This indicates that the path the SDK was installed to is available in your includes (i.e. falls below /usr/share/pear).

You will note that ownership of the SDK files is set to root - with 0644 permissions. The user Apache is running as is presumably neither root, nor in the root group. It should therefore be able to read the files, but not modify them.

/root is the home directory of the user root. The getenv() and setenv() functions are PHP, and need to go in a PHP file - not an INI file.

You don't need to use the environment variables for the method above. However, if you place your configuration in your HOME directory (as per method 2), then PHP needs to know your home directory in order to read the file (there are potentially other issues with this, in that many installations will restrict access to certain folders only, e.g. using open_basedir).

Using the second approach, you will need to verify that PHP can determine your HOME directory. You can create a PHP file and test the getenv() function. If all is well (i.e. you get the correct HOME path - the directory containing your configuration file), then you don't need to use that or the setenv() function at all.

If, on the other hand, the path is incorrect, then you will need to set the correct home path at the top of your script (i.e. the one using the SDK, before you reference it). Essentially, you are exporting the path to the directory containing the .aws folder that you have your configuration in - whenever you call the SDK that variable will need to be set.

As for the response you got (i.e. /root) - if you run the php script from the command line as root, then the response was expected. If you ran it through a web browser, then something isn't quite right. Apache is typically set up as its own user (UID=48), with its home directory set to /var/www - regardless, Apache should not be running as root. Typically, Apache is started as root and then changes to the user specified in your httpd.conf file. If you are running suPHP or php-fpm then there is a good chance that PHP is not running as the same user as the web server. Note that you can run the same script as different users, and will get a different response each time - run it under the conditions you expect it to be run as (i.e. if the script it intended to be accessed via a browser, do so; if it will be a shell script then run it as such).

Best Answer

Related Solutions

Mysql – Percona MySQL 5.5 fails to start

EC2 – AWS SDK – config.inc.php where

Related Topic