Mike Spreitzer wrote:
> Sorry if I have confused people by presenting
> evidence in the wrong order. Also, it seems that the .sql file is
> written by the client while the .txt file is (attempted to be) written
> by the server. Here is a single typescript with all the evidence:
>
> [root@xd026 ~]# cd /
>
> [root@xd026 /]# rm -f dump1/*
>
> [root@xd026 /]# ls -ld dump1
>
> drwxrwxrwx 2 mysql mysql 4096
> Feb 22 20:45 dump1
>
> [root@xd026 /]# ls -l dump1
>
> total 0
>
> [root@xd026 /]# mysqldump -u root -p
> --skip-opt --quick --tab=/dump1 wyky red1_p2
>
> Enter password:
> mysqldump: Got error: 1: Can't create/write
> to file '/dump1/red1_p2.txt' (Errcode: 13) when executing 'SELECT INTO
> OUTFILE'
>
^^^^
I'm reading thru http://dev.mysql.com/doc/refman/5.0/en/select.html and it says
that it will not write to an already existing file (so you deleted the old files)
and you need the FILE privilege, and that it writes the file mode 777 as the user
running the client (and suggests not using root).
I would try
$ rm -f /dump1/*
$ echo "SELECT * FROM red1_p2 INTO OUTFILE '/dump1/red1_p2.txt';" \
| mysql -u root -p
to see if this is a mysql permissions issue. The above will create a file
owned by the mysql process.
You might try changing the directory to /tmp or /var/tmp to see if that
makes some kind of magical difference.
Might also check your grants for root@localhost. Unlikely, but possible.
Also, check /var/log/messages and if there's any SELinux warnings.
You might have the option 'secure_file_priv' set?
http://dev.mysql.com/doc/refman/5.0/en/server-options.html#option_mysqld_secure-file-priv
Jed
