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

È stato utile?

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

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top