Comment contourner MySQL Errcode 13 avec SELECT INTO OUTFILE?

J'essaie de vider le contenu d'une table dans un fichier csv en utilisant une instruction MySQL SELECT INTO OUTFILE. Si je fais:

SELECT column1, column2
INTO OUTFILE 'outfile.csv'
FIELDS TERMINATED BY ','
FROM table_name;

outfile.csv sera créé sur le serveur dans le même répertoire dans lequel les fichiers de cette base de données sont stockés.

Cependant, lorsque je change ma requête en:

SELECT column1, column2
INTO OUTFILE '/data/outfile.csv'
FIELDS TERMINATED BY ','
FROM table_name;

Je reçois:

ERROR 1 (HY000): Can't create/write to file '/data/outfile.csv' (Errcode: 13)

Errcode 13 est une erreur d'autorisations, mais je l'obtiens même si je change la propriété de / data en mysql: mysql et lui donne des autorisations 777. MySQL fonctionne en tant qu'utilisateur "mysql".

Étrangement, je peux créer le fichier dans / tmp, mais pas dans un autre répertoire que j'ai essayé, même avec des autorisations définies de sorte que l'utilisateur mysql puisse écrire dans le répertoire.

Il s'agit de MySQL 5.0.75 fonctionnant sous Ubuntu.

De quelle version particulière d'Ubuntu s'agit-il et s'agit-il d'Ubuntu Server Edition?

Les éditions récentes d'Ubuntu Server (telles que 10.04) fournies avec AppArmor et le profil de MySQL peuvent être en mode d'application par défaut. Vous pouvez vérifier cela en exécutant sudo aa-statuscomme suit:

# sudo aa-status
5 profiles are loaded.
5 profiles are in enforce mode.
   /usr/lib/connman/scripts/dhclient-script
   /sbin/dhclient3
   /usr/sbin/tcpdump
   /usr/lib/NetworkManager/nm-dhcp-client.action
   /usr/sbin/mysqld
0 profiles are in complain mode.
1 processes have profiles defined.
1 processes are in enforce mode :
   /usr/sbin/mysqld (1089)
0 processes are in complain mode.

Si mysqld est inclus en mode enforce, alors c'est probablement celui qui refuse l'écriture. Les entrées seraient également écrites /var/log/messageslorsque AppArmor bloque les écritures / accès. Ce que vous pouvez faire est de modifier /etc/apparmor.d/usr.sbin.mysqldet d'ajouter /data/et /data/*près du bas comme ceci:

...  
/usr/sbin/mysqld  {  
    ...  
    /var/log/mysql/ r,  
    /var/log/mysql/* rw,  
    /var/run/mysqld/mysqld.pid w,  
    /var/run/mysqld/mysqld.sock w,  
    **/data/ r,  
    /data/* rw,**  
}

Et puis faites AppArmor recharger les profils.

# sudo /etc/init.d/apparmor reload

AVERTISSEMENT: le changement ci-dessus permettra à MySQL de lire et d'écrire dans le répertoire / data. Nous espérons que vous avez déjà pris en compte les implications en matière de sécurité.

Ubuntu utilise AppArmor et c'est ce qui vous empêche d'accéder à / data /. Fedora utilise selinux et cela empêcherait cela sur une machine RHEL / Fedora / CentOS.

Pour modifier AppArmor pour permettre à MySQL d'accéder à / data /, procédez comme suit:

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

ajoutez cette ligne n'importe où dans la liste des répertoires:

/data/ rw,

puis faites un:

sudo /etc/init.d/apparmor restart

Une autre option consiste à désactiver complètement AppArmor pour mysql, ce n'est PAS RECOMMANDÉ :

sudo mv /etc/apparmor.d/usr.sbin.mysqld /etc/apparmor.d/disable/

N'oubliez pas de redémarrer apparmor:

sudo /etc/init.d/apparmor restart

Je sais que vous avez dit que vous avez déjà essayé de définir les autorisations sur 777, mais comme j'ai la preuve que pour moi, c'était un problème d'autorisation, je poste ce que je lance exactement en espérant que cela puisse aider. Voici mon expérience:

tmp $ pwd
/Users/username/tmp
tmp $ mkdir bkptest
tmp $ mysqldump -u root -T bkptest bkptest
mysqldump: Got error: 1: Can't create/write to file '/Users/username/tmp/bkptest/people.txt' (Errcode: 13) when executing 'SELECT INTO OUTFILE'
tmp $ chmod a+rwx bkptest/
tmp $ mysqldump -u root -T bkptest bkptest
tmp $ ls bkptest/
people.sql  people.txt
tmp $ 

MySQL devient stupide ici. Il essaie de créer des fichiers sous / tmp / data / .... Donc ce que vous pouvez faire est ce qui suit:

mkdir /tmp/data
mount --bind /data /tmp/data

Ensuite, essayez votre requête. Cela a fonctionné pour moi après des heures de débogage du problème.

Ce problème me dérange depuis longtemps. J'ai remarqué que cette discussion ne précise pas la solution sur RHEL / Fecora. J'utilise RHEL et je ne trouve pas les fichiers de configuration correspondant à AppArmer sur Ubuntu, mais j'ai résolu mon problème en rendant TOUS les répertoires du répertoire PATH lisibles et accessibles par mysql. Par exemple, si vous créez un répertoire / tmp, les deux commandes suivantes permettent à SELECT INTO OUTFILE de sortir le fichier .sql ET .sql

chown mysql:mysql /tmp
chmod a+rx /tmp

Si vous créez un répertoire dans votre répertoire personnel / home / tom, vous devez le faire pour / home et / home / tom.

Tu peux le faire :

mysql -u USERNAME --password=PASSWORD --database=DATABASE --execute='SELECT `FIELD`, `FIELD` FROM `TABLE` LIMIT 0, 10000 ' -X > file.xml

Quelques choses à essayer:

• la secure_file_privvariable système est-elle définie? Si tel est le cas, tous les fichiers doivent être écrits dans ce répertoire.
• assurez-vous que le fichier n'existe pas - MySQL ne créera que de nouveaux fichiers et n'écrasera pas les fichiers existants.

J'ai le même problème et j'ai résolu ce problème en suivant les étapes:

• Système d'exploitation: ubuntu 12.04
• lampe installée
• supposons que votre répertoire pour enregistrer le fichier de sortie soit: / var / www / csv /

Exécutez la commande suivante sur le terminal et modifiez ce fichier à l'aide de l'éditeur gedit pour ajouter votre répertoire au fichier de sortie.

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

• maintenant le fichier serait ouvert dans l'éditeur, veuillez y ajouter votre répertoire

  / var / www / csv / * rw,

• de même, j'ai ajouté dans mon fichier, comme suit l'image donnée:

Exécutez la commande suivante pour redémarrer les services:

sudo /etc/init.d/apparmor redémarrer

Par exemple, j'exécute la requête suivante dans le générateur de requêtes phpmyadmin pour générer des données dans un fichier csv

SELECT colName1, colName2,colName3
INTO OUTFILE '/var/www/csv/OUTFILE.csv'
FIELDS TERMINATED BY ','
FROM tableName;

Il a réussi et a écrit toutes les lignes avec les colonnes sélectionnées dans le fichier OUTPUT.csv ...

Dans mon cas, la solution était de rendre tous les répertoires du chemin d'accès lisibles et accessibles par mysql( chmod a+rx). Le répertoire était toujours spécifié par son chemin relatif dans la ligne de commande.

chmod a+rx /tmp
chmod a+rx /tmp/migration
etc.

Je viens de rencontrer ce même problème. Mon problème était que le répertoire dans lequel j'essayais de vider n'avait pas l'autorisation d'écriture pour le processus mysqld. Le vidage SQL initial écrirait mais l'écriture du fichier csv / txt échouerait. On dirait que le vidage sql s'exécute en tant qu'utilisateur actuel et la conversion en csv / txt est exécutée en tant qu'utilisateur qui exécute mysqld. Le répertoire a donc besoin d'autorisations d'écriture pour les deux utilisateurs.

Vous devez fournir un chemin absolu, pas un chemin relatif.

Indiquez le chemin complet du répertoire / data dans lequel vous essayez d'écrire.

Ubuntu utilise-t-il SELinux? Vérifiez s'il est activé et en vigueur. /var/log/audit/audit.log peut être utile (si c'est là que Ubuntu le colle - c'est l'emplacement RHEL / Fedora).

J'ai eu le même problème sur un CentOs 6.7 Dans mon cas, toutes les autorisations ont été définies et l'erreur s'est toujours produite. Le problème était que le SE Linux était dans le mode "enforcing".

Je l'ai commuté sur "permissif" en utilisant la commande sudo setenforce 0

Puis tout a fonctionné pour moi.