I have various MySQL databases on different servers and at different versions. I'm using the same mysqldump command across Linux versions without issue except for this new Red Hat 7.6 server.


mysqldump --tab=/var/tmp/mysql/mysql.20190808/wikidb \
--opt --user=root --password=[password] wikidb

Prior to the mysqldump command:

mkdir -p /var/tmp/mysql/mysql.20190808/wikidb
chown -R mysql:mysql /var/tmp/mysql/mysql.20190808
chmod 777 /var/tmp/mysql/mysql.20190808

This is all scripted so no chance for a typo.

On all the older servers, and especially the older wiki servers this server is replacing, the command works successfully. I get a list of all the tables and .txt files for the database in the directory.

On the new server, I get the very first table, back_archive.sql, and then an error:

mysqldump: Got error: 1: "Can't create/write to file '/var/tmp/mysql/mysql.20190808/wikidb/back_archive.txt' (Errcode: 2)" when executing 'SELECT INTO OUTFILE'

I've tried various permissions including 1777 to give it a sticky bit just in case and it still fails. Ownership is confirmed as mysql:mysql and the database owner is mysql.

I'd done quite a bit of searching and reading of the man pages and everyone pretty much blames it on ownership or directory permissions but as noted above, I believe I've done it correctly, especially since it's a script and is working on every other server.

I will note this is my first master/master replication server. I didn't find anything specific regarding this sort of configuration but I thought I'd mention it.

2 Answers 2


[Lots of] Other things can get in the way.

SELinux can cause all sorts of problems, making really basic things fail for no apparent [or announced] reason.

ACL's in the file system can cause confusion, sneakily "tweaking" permissions without you realising it.

Is it possible that the MySQL configuration is different?
These days, a clean install of MySQL might well come with --secure-file-priv turned on. If that doesn't match where you're trying to put the file, you'll hit another wall.

Regards, Phill W.

  • I guess the main reply is that it writes one file, the .sql table, and then can't write any more files, the .txt data file. I manage the server so I know SELinux is disabled and we're not using ACLs. And I just verified that the --secure-file-priv option isn't enabled in my.cnf or any of the my.cnf.d files.
    – Freejack
    Commented Aug 9, 2019 at 13:48
  • systemd defaults of ProtectHome and ProtectSystem also significantly restrict write locations.
    – danblack
    Commented Mar 10, 2022 at 3:45

I found the initial problem which was the txt files were being stored in a protected directory in /var/tmp.

The solution however was to store the files into a directory outside of the /tmp and /var/tmp directory structure. The powers that be decided that the output shouldn't be viewable to the non-mysql account so worked around it by putting into a hashed directory in /var/tmp.

I changed the output directory to /opt/mysqlbackup and haven't had a problem since.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.