Mysql ERRORE 1005 (HY000): Impossibile creare la tabella 'tmp' (errno: 13)
-
21-09-2019 - |
Domanda
Sono in esecuzione MySQL su Ubuntu 9.10, il processo di MySQL è in esecuzione come root, sta utilizzando un account di root quando si accede a MySQL, che ho dato tutti i privilegi, sto usando il mio db (non MySQL), posso creare un tavolo, ma quando provo a creare tabella temporanea ottengo questo errore:
ERRORE 1005 (HY000): Impossibile creare la tabella 'tmp' (errno: 13)
Per questa query:
CREATE TEMPORARY TABLE tmp (id int);
Ho un sacco di spazio nel mio disco rigido, tutte le autorizzazioni vengono concesse (anche permessi var / lib / mysql Hanno mysql).
Qualche idea? Grazie, Koby
Soluzione 2
Bene ... in /etc/mysql/my.cnf c'è la cartella "tmp" per l'uso che è / tmp (da root) come predefinito .. e non hanno i privilegi di MySQL. chmod 0777 / tmp farà il trucco
Altri suggerimenti
Ho avuto lo stesso problema un paio di settimane fa.
La cartella di database sul filesystem è stato di proprietà dell'utente sbagliato.
Un semplice chown -R mysql:mysql /var/lib/mysql/database_name
ha fatto il trucco!
E 'tutto spiegato qui: http://www.dinosources.eu/ 2010/10 / mysql-cant-creare-tavolo (è italiano, ma è abbastanza chiaro)
Saluti
Ho avuto l'errore di cui sopra con le autorizzazioni corrette per / tmp, contesto corretto e sufficiente spazio su disco su Fedora 16.
Dopo una giornata di strappo i miei capelli, ho rintracciato il problema a un ambiente in configurazione systemd per il servizio MySQL.
Nel controllo /etc/systemd/system/multi-user.target.wants/mysqld.service
perché se c'è un PrivateTmp=true
impostazione. Questo le forze del cambiamento MySQL per usare una / tmp / systemd-namespace-XXXXX sottodirectory invece di mettere i file direttamente in / tmp. A quanto pare MySQL non così e non riuscire con un errore di negato il permesso (13) per qualsiasi domanda che ha richiesto la creazione di un file temporaneo.
È possibile ignorare questa impostazione nel seguente modo:
cat >> /etc/systemd/system/mysqld.service << END_CONFIG
.include /lib/systemd/system/mysqld.service
[Service]
PrivateTmp=false
END_CONFIG
Poi ricaricare la configurazione da corsa: systemctl daemon-reload
e riavviare MySQL
si fa a impostare le MaxNoOfOrderedIndexes attributo nel config.ini? E 'il valore di default è 128, quindi se avete un sacco di tavoli per creare, ultima delle quali non può essere creato. vedere: http: // dev .mysql.com / doc / refman / 5.1 / it / mysql-cluster-ndbd-definition.html # ndbparam-ndbd-maxnooforderedindexes
Ho avuto lo stesso problema di oggi sul mio esempio Amazon Red Hat. Sono stato in grado di svolgere non descriveremo mysql (da shell mysql) né eseguire mysqldump. Per risolvere questo ho cercato la soluzione più ovvia:
# chown root:root /tmp -v
# chmod 1777 /tmp -v
# /etc/init.d/mysqld restart
Ma questo non ha aiutato. Nel /var/log/mysqld.log ho ancora visto:
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.
E 'venuto fuori che si trattava di SELinux che non consentiva MySQL demone per scrivere a / tmp. Perciò, quello che ho fatto è stato quello di:
# getenforce
Enforcing
Per verificare se SELinux è in esecuzione in modalità enforcing (si può leggere di più su questo qui ). La soluzione veloce e rapido per questo è stato quello di passare alla modalità permissiva SELinux:
# setenforce 0
# getenforce
Permissive
# /etc/init.d/mysqld restart
È possibile che questo risolto il mio problema.
Si noti che, se si sta lavorando sulla produzione indurito, si dovrebbe essere molto attenti quando si passa da far rispettare a permissiva. Si prega di notare che questa impostazione specifico sarà azzerato dopo il riavvio.
stavo avendo questi (errno: 13) gli errori e solo capito dopo aver guardato in / var / log / syslog, quindi il mio consiglio è questo:
tail -f /var/log/syslog
Vedere se questo ha qualcosa a che fare con file di database dopo il tentativo di accedere al database, nel mio caso è stato
apparmor=[DENIED]
Il che significa che è necessario trattare con AppArmor, ma nel tuo caso potrebbe essere qualcos'altro.
con il mio caso:
# semanage fcontext -a -t mysqld_db_t "/datadir(/.*)?"
# restorecon -Rv /datadir
#chcon -R -t mysqld_db_t /datadir
risolto il mio problema.
Se installato PhpMyAdmin con XAMPP su Linux, l'utente può essere impostato in questo percorso:
sudo chown -R mysql:mysql /opt/lampp/var/mysql/my_database