7

I installed mysql on a brand-new Fedora 16 server and it would not start. This is the line from the log file (^G and all):

^G/usr/libexec/mysqld: Can't create/write to file '/tmp/ibNPyIlu' (Errcode: 13)

I looked at /tmp/ and it has rather strange-looking permissions:

drwxrwxrwt.

Why the dot? chmod 1777 does not change anything. Is this responsible for the error? What's next?

George M
  • 13,589
  • 4
  • 43
  • 53
KateYoak
  • 735
  • 1
  • 8
  • 13

5 Answers5

5

The dot means there is an ACL (access control list) overriding the usual Unix permission scheme. Here's what mine looks like:

$ ls -ld /tmp
drwxrwxrwt. 7 root root 4096 Apr 23 22:36 /tmp

$ getfacl /tmp
getfacl: Removing leading '/' from absolute path names
# file: tmp
# owner: root
# group: root
# flags: --t
user::rwx
group::rwx
other::rwx

Check your /tmp directory. If it differs, use setfacl to correct it.

Barry Brown
  • 461
  • 4
  • 12
  • Thanks! This is new. :-) I should dig around to learn more about it. This was not the cause for my problem in the end, but what a nice piece of knowledge! – KateYoak Apr 24 '12 at 20:37
  • No, the dot means the opposite. A `+` means there are extended ACLs. – Mikel Apr 26 '12 at 02:39
  • `getfacl` is showing you the file has only minimal ACLs. See http://www.suse.de/~agruen/acl/linux-acls/online/ – Mikel Apr 26 '12 at 02:54
5

Error 13 is probably system error 13, which means permission denied.

$ perror 13
OS error code  13:  Permission denied

A dot means the file has an SELinux context.

GNU coreutils - What information is listed

GNU ls uses a ‘.’ character to indicate a file with an SELinux security context, but no other alternate access method.

A file with any other combination of alternate access methods is marked with a ‘+’ character.

You can display the SELinux context by running ls -Z, e.g.

$ ls -dZ /tmp
drwxrwxrwt. root root system_u:object_r:tmp_t:s0       /tmp

Next steps are:

  • look in /var/log/messages
  • look in /var/log/audit/audit.log
  • try running ausearch or sealert

See:

Community
  • 1
Mikel
  • 56,387
  • 13
  • 130
  • 149
4

This was a bug with mysqld starting with systemd when they made a change to use ServicesPrivateTmp for additional security. When you performed a yum update, the mysql package was updated to mysql-5.5.22-1.fc16 or greater which corrected the issue.

George M
  • 13,589
  • 4
  • 43
  • 53
2

SELinux can be tricky to configure with MySQL

Fedora and Red Hat are using SELinux (see in /etc/sysconfig/selinux if SELINUX has a value of "enforcing"). I had installed (2 years ago) MySQL on RHEL 5 and I had to tweak SELinux so it would play nicely with MySQL.

If it is not an ACL permission deny (like sugested by Barry Brown) then try to look if by setting SELINUX to "permissive" (and rebooting) this does not solve your problem. Setting SELinux to permissive will not deny a process the access it requests, but it will be still logged. So if SELinux is the culprit, you will get informed in the logs and MySQL will anyway be able to start.

If it did solve your problem but you want to keep SELinux activated, look for SELinux+MySQL+Fedora, I had found plenty of resources 2 years ago on this matter. Things might have changed since that time and might depends on MySQL versions, etc. So I cannot give you better advice than pointing you in the right direction. :)

Huygens
  • 8,985
  • 3
  • 31
  • 36
1

The problem did not have to do with permissions - though I was thrilled to get the answer above to satisfy my curiosity. Instead, I discovered that I had not run

 yum update

after the initial Fedora installation. I guess, the bug got fixed somewhere in there after the original release of Fedora 16. Duh.

KateYoak
  • 735
  • 1
  • 8
  • 13