Подтвердить что ты не робот

Mysql ERROR 1005 (HY000): не удается создать таблицу 'tmp' (errno: 13)

Я запускаю Mysql на ubuntu 9.10, процесс Mysql работает под управлением root, я использую учетную запись root при регистрации в Mysql, который я дал всем привилегиям, я использую свой собственный db (а не mysql), я могу создать таблицу, но когда я пытаюсь создать Временная таблица: я получаю эту ошибку:

ОШИБКА 1005 (HY000): невозможно создать таблицу 'tmp' (errno: 13)

Для этого запроса:

CREATE TEMPORARY TABLE tmp (id int);

У меня много места на моем жестком диске, все разрешения предоставлены (также var/lib/mysql имеют разрешения mysql).

Любая идея? Благодаря, Коби

4b9b3361

ОТВЕТЫ

Ответ 1

Ну... в /etc/mysql/my.cnf там используется папка "tmp", которая является /tmp (от root) по умолчанию.. и не имеет привилегий mysql. chmod 0777/tmp сделает трюк

Ответ 2

У меня была такая же проблема пару недель назад. Папка базы данных в файловой системе принадлежала неправильному пользователю. Простой chown -R mysql:mysql /var/lib/mysql/database_name сделал трюк!

Все объяснено здесь: http://www.dinosources.eu/2010/10/mysql-cant-create-table (это итальянское, но это довольно ясно)

Приветствия

Ответ 3

У меня была ошибка выше с правильными разрешениями на /tmp, правильный контекст и достаточное дисковое пространство на Fedora 16.

После дня вырывания моих волос, я отследил проблему до настройки в конфигурации systemd для службы MySQL.

В /etc/systemd/system/multi-user.target.wants/mysqld.service проверьте, есть ли настройка PrivateTmp=true. Это изменение заставляет MySQL использовать подкаталог /tmp/systemd -namespace-XXXXX вместо помещения файлов непосредственно в /tmp. По-видимому, MySQL этого не нравится, и с ошибкой (13) разрешен отказ для любого запроса, требующего создания временного файла.

Вы можете переопределить этот параметр следующим образом:

cat >> /etc/systemd/system/mysqld.service << END_CONFIG
.include /lib/systemd/system/mysqld.service
[Service]
PrivateTmp=false
END_CONFIG

Затем перезагрузите конфигурацию, запустив: systemctl daemon-reload и перезагрузите MySQL.

Ответ 5

У меня была такая же проблема сегодня на моем экземпляре Amazon Red Hat. Мне не удалось выполнить ни mysql decribe (из оболочки mysql), ни выполнить mysqldump. Чтобы решить эту проблему, я попробовал наиболее очевидное решение:

# chown root:root /tmp -v
# chmod 1777 /tmp -v
# /etc/init.d/mysqld restart

Но это не помогло. В файле /var/log/mysqld.log я все еще видел:

141022 10:23:35  InnoDB: Error: unable to create temporary file; errno: 13
141022 10:23:35 [ERROR] Plugin 'InnoDB' init function returned error.
141022 10:23:35 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.

Вышло, что SELinux не позволял демону MySQL писать в /tmp. Поэтому я сделал следующее:

# getenforce 
Enforcing

Чтобы проверить, работает ли SELinux в режиме принудительного выполнения (вы можете прочитать об этом здесь). Быстрое и быстрое решение для этого заключалось в переключении в разрешающий режим SELinux:

# setenforce 0
# getenforce 
Permissive
# /etc/init.d/mysqld restart

Вышеупомянутая проблема решена.

Обратите внимание, что если вы работаете над закаленным производством, вы должны быть очень осторожны, когда переходите от принудительного к разрешению. пожалуйста, также обратите внимание, что после перезагрузки эта настройка будет reset.

Ответ 6

У меня были эти ошибки (errno: 13), и выяснили их только после просмотра /var/log/syslog, поэтому я советую:

tail -f /var/log/syslog

Посмотрите, связано ли это с файлами базы данных после попытки доступа к базе данных, в моем случае это было

apparmor=[DENIED]

Это означает, что вам нужно иметь дело с apparmor, но в вашем случае это может быть что-то еще.

Ответ 7

с моим случаем:

    # semanage fcontext -a -t mysqld_db_t "/datadir(/.*)?"
    # restorecon -Rv /datadir
    #chcon -R -t mysqld_db_t /datadir

решил мою проблему.

Ответ 8

Если в Linux установлен PhpMyAdmin с XAMPP, пользователь может указать этот путь:

sudo chown -R mysql:mysql/opt/lampp/var/mysql/my_database