I run ubuntu 12.04.
I am trying to move the temp dir for files as /tmp has filled up, somehow I only set it to 1meg, which is obviously not enough for a large mysql database.
What I need to do is move it on, so I looked online for a solution to this and I found an article which seems to make sense.
In the my.conf file at /etc/mysql/my.conf I changed the tmpdir directive to /mysqltmp. I made the directory with root login, then chmod 777 that dir. I reboot and the mysql server wont start. (it was starting just previously).
The error log says..
/usr/sbin/mysqld: Can't create/write to file '/mysqltmp/ibqADloJ'
It's a permissions error, however the directory has full permissions so why is this a problem?
Probably apparmor is getting in your way. Have a look at /etc/apparmor.d/usr.sbin.mysqld and make your new temp-folder writable by the mysqld process (or configure mysqld to write its temporary data to a directory it has write permissions for)
Related
I've a Galera Cluster Installation with three nodes. As requirement my MariaDB installation must be in different path that default, and user cannot be mysql. So I've moved all mysql data path and I've created a new user and group to manage the mysql service.
MariaDB service is working fine, but I've noticed that a mysql-slow.log has been created with permissions to mysql:root for a third program installation that monitor queries. Opening mysql.err I've found the following error:
[ERROR] Could not use mysql-slow.log for logging (error 13).Turning logging off for the whole duration of the MySQL server process. To turn it on again: fix the cause, shutdown the MySQL server and restart it.
So I've made chown myuser:mygroup mysql-slow.log and restart the service, but there still having same permissions. Then I've set in my.cnf the slow_query_log=1, in order to try that the myuser create the file at start, but the wrong permission still there also after remove the files and restart.
All the files, in my mariadb data path, are not managed by mysql:mysql user, in my installation are managed by myuser:mygroup so when the mysql-slow.log is created the permissions mysql:root are assigned so I have not permission to write there with myuser:mygroup and if I assign them manually there is not effect because are override with mysql:root after mysql restart.
Somebody knows if there are any way to set by default the user and group owners of the mysql-slow.log file when created?
Thanks.
Regards,
Sergio
Fix the permissions:
chmod 666 mysql-slow.log
See what your script is doing; perhaps it needs fixing, too.
I have a LAMP stack setup. Occasionally, I get the following error message when I open some page from the browser:
Error creating the connection!: SQLSTATE[HY000] [2002] Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)
I think the server was configured correctly. The problem happens about every two months. Every time when I reboot the Linux server, or restart mysql, the problem was gone. I want to fix this problem permanently. Can anyone give me some idea?
Much appreciated.
EDIT
The problem occurs again and I checked the mysqld.sock file, it was not there. Do you have any idea how to fix the problem? – Ryan Jul 23 at 16:24
If your file my.cnf (usually in the /etc/mysql/ folder) is correctly configured with
socket=/var/run/mysqld/mysqld.sock
modified
#bind-address = 127.0.0.1
to
bind-address = localhost
you can check if mysql is running with the following command:
mysqladmin -u root -p status
try changing your permission to mysql folder. If you are working locally, you can try:
sudo chmod -R 755 /var/run/mysqld/
And then restart the mysql.
Good luck.
Could it be the log file getting too large and rebooting flushes it. See this in docs on server maintenance and logfiles. Also see discussion at digital ocean. Appears to be confirmed by discussion at serverfault
You could try change the permission of your MySQL sock file like this:
chmod 777 '/var/run/mysqld/mysqld.sock'
It is a test to see if whatever user mysqld is using, it will acess your mysqld.sock file. So, reboot your MySQL and change the permission of mysqld.sock. And you need to check that if your sock folder can be accessed through any mysqld process.
If the mysqld.sock file doesn't exist, that is to say your config file is not correct.Check your mysql config file in /etc/mysql/my.conf, find the socket config just as Vanya Avchyan says.
I think the socket config is /var/run/mysqld/mysqld.sock, but in fact your mysql process runs in other place sock file.
I used to met that problem, the real socket file exists in /tmp/mysqld.sock.
So run
sudo find / -name 'mysqld.sock'
to find the real sock file and change my.conf to this real place, restart your mysql. May have work.
I've been struggling for a couple of days with this now and have been trying to use this thread amongst other google searches to resolve it but can't seem to get it to work.
When I run this SELECT query (Ubuntu Server 15.10 & MySQL 5.6)...
SELECT column1 ,column2
FROM table
INTO OUTFILE '/home/user/mysql_temp/file.csv';
I get this permission error...
ERROR 1 (HY000): Can't create/write to file '/home/mysql_temp/file.csv' (Errcode: 13 - Permission denied)
From my searching, I understand this to be a system permissions issue rather than a MySQL problem but I can't seem to find a solution which fixes it for me.
Checking apparmor shows that mysqld IS in enforce mode...
apparmor module is loaded.
6 profiles are loaded.
6 profiles are in enforce mode.
/sbin/dhclient
/usr/lib/NetworkManager/nm-dhcp-client.action
/usr/lib/NetworkManager/nm-dhcp-helper
/usr/lib/connman/scripts/dhclient-script
/usr/sbin/mysqld
/usr/sbin/tcpdump
0 profiles are in complain mode.
2 processes have profiles defined.
2 processes are in enforce mode.
/sbin/dhclient (676)
/usr/sbin/mysqld (1285)
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.
So I edited /etc/apparmor.d/usr.sbin.mysqld and added the following lines and then restarted apparmor...
/home/user/mysql_temp/ rw,
/home/user/mysql_temp/* rw,
I also changed the owner:group of mysql_temp to mysql and gave it full permissions...
sudo chown mysql:mysql mysql_temp
...
drwxrwxrwx 2 mysql mysql 6 Apr 1 22:02 mysql_temp
After this, I still receive the same error.
Have I missed something? Misunderstood some of the instruction? Would be grateful for advice. Thanks.
What worked for me was accessing the my.ini file. Within that file, look for "Secure File Priv." There should be a file path which is the secure route mySql gives permissions to output the designated file. I hope this helps! For me, the file was under C:/ProgramData/mysql/mysql Server 5.7
Solution Based On; Ubuntu 20.10 with Apparmor active and MySql 8
Solution Summary and Lesson Learned:
Unless you have a damn good reason not to
Leave the default secure-file-priv settings alone,
Give your user(s) FILE privileges in mysql,
And tell apparmor to allow writing to the default directory set up by the mysql installer.
The default configuration set secure-files-priv to /var/lib/mysql-files. Left as it was, I was able to import files by placing them in that directory so long as I gave the user file privileges like so, GRANT FILE ON *.* TO myuser#host;
However, when I tried to write to that directory I got the dreaded Error Code: 1. Can't create/write to file '/var/lib/mysql-files/select_out.csv' (OS errno 13 - Permission denied). I could have solved this very easily by editing /etc/apparmor.d/usr.sbin.mysqld and changing
# Allow data files dir access
/var/lib/mysql-files/ r,
/var/lib/mysql-files/** rwk,
to
# Allow data files dir access
/var/lib/mysql-files/ rw,
/var/lib/mysql-files/** rwk,
But I didn't know about apparmor at the time, and so I fumbled around screwing up more stuff until I found #spcurtis81's post. If that's what happened to you, read on, maybe you can learn something from my journey.
Unfortunately at some point - and god only knows why - I decided to move the secure-file-priv directory to /mysql-files. This created a lot more work for me. If nothing else it taught me a lot, and gave me the opportunity to share.
I had to change the 'secure-files-priv' setting under [mysqld] section in one of .cnf files, but which, there are so damn many. I found it by doing this,
cd /
find . -name "*.cnf" -printf '%p\n' -exec grep "\[mysqld\]" {} \;
and getting
./conf.d/mysqldump.cnf
./conf.d/mysql.cnf
./my.cnf
./debian.cnf
./mysql.conf.d/mysqld.cnf
[mysqld]
./mysql.conf.d/mysql.cnf
./mysql.cnf
so the file above the [mysqld] was the one for me. I found several references to modifying my.cnf but as it didn't already have the section in it, I went with mysqld.cnf. I also reckoned that the mysqld.cnf was for the server daemon as opposed to the user program. It worked, so it aint stupid, but perhaps a more knowledgeable person could explain the hierarchy of .cnf files.
There was no existing secure-files-priv entry for this setting so I found what seemed to be a reasonable location for it and added the following.
# Added 12/13/2020 in an attempt to relocate the secure-file-priv directory
secure-file-priv = /mysql-files
No joy. I found another reference that said that you had to specify a temp directory and so I uncommented this line from the same file.
# If MySQL is running as a replication slave, this should be
# changed. Ref https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_tmpdir
tmpdir = /tmp
Still no joy. Then I found #spcurtis81's post here and learned about the apparmor settings. So in /etc/apparmor.d/usr.sbin.mysqld I changed
# Allow data files dir access
/var/lib/mysql-files/ r,
/var/lib/mysql-files/** rwk,
to
# Allow data files dir access
/mysql-files/ rw,
/mysql-files/** rwk,
AND still no f-ing joy!
The final step that resolved the issue: chmod -R 700 /mysql-files
When I had created the directory I set the owner to mysql and gave it 644 permissions. That seemed reasonable but added an error to my mysql error log: 'Insecure configuration for --secure-file-priv: Location is accessible to all OS users. Consider choosing a different directory.'
I don't like security warnings so I changed the permission to 600, never thinking mysql would need executable rights on a data directory. I was wrong. So, there you go.
It's an directory error where you storing the data.
give the permission to the folder where data is store in your case the data store in the "mysql_temp"
use the command "$ chmod 777 mysql_temp"
Don't forget, you have to reload apparmor.
$ sudo service apparmor reload
If mysqld is included in enforce mode, then the entries can be written in /var/log/messages when AppArmor blocks the writes/accesses.
You can edit /etc/apparmor.d/usr.sbin.mysqld and add /home/user/mysql_temp/ and /home/user/mysql_temp/* near the bottom like this:
/usr/sbin/mysqld {
...
/var/log/mysql/ r,
/var/log/mysql/* rw,
/var/run/mysqld/mysqld.pid w,
/var/run/mysqld/mysqld.sock w,
**/home/user/mysql_temp/ r,
/home/user/mysql_temp/* rw,**
}
And then you can make AppArmor reload the profiles.
# sudo /etc/init.d/apparmor reload
WARNING: The above change will allow MySQL to read and write to the /home/user/mysql_temp/ directory.
Change ownership of the specified directory to mysql user.
chown mysql:mysql /data/data-directory
the original question was writing to an outfile here:
INTO OUTFILE '/home/user/mysql_temp/file.csv';
the problem could be a mysql configuration; and not apparmor.
if you are running with systemd, look at this setting in /etc/systemd/system/mysql.service:
# Prevent accessing /home, /root and /run/user
ProtectHome=true
assuming all of the file permissions are correct, one would need to change this to false to write to the /home directory.
I am running on Ubuntu and I've modified /etc/mysql/my.cnf with the following:
pastie of my.cnf and i've chown it to mysql:mysql and chmoded it to 777. No matter what I try when I run a few queries nothing gets logged. What am I doing wrong? I have also tried commenting out general_log_file and general_log and use log = and its its the same thing.
update: i did restart mysql after changes.
update: here is the mysql variables: http://pastie.org/5517087
I suggest you to check the following:
1) Make sure that you restarted the service and that no errors appear during the restart, either on the command prompt, or in the mysql error log file
2) In your my.cnf you are using:
general_log_file = /var/www/logs/mysql-query.log
make sure that the user mysqld (or whatever your mysql service is running as), has the proper permissions to write this folder. The /var/www/ folder is usually intended for apache usage, not mysql usage, so I would suggest /var/log/ or /var/log/mysqld
3) Make sure that the my.cnf you are editing, is the one your mysqld is really running. In many cases when you are using some other software (like cpanel, plesk, etc), the default folders are not used and the configs being used are somewhere else. You can search around your system for other my.cnf using:
locate my.cnf
I installed LAMP on Ubuntu 11.04 and copy project from Windows.
PHP directory (/ci/) to var/www/
and
MySQL project directory (/ci/) to var/lib/mysql/
Full text of error that i get:
A Database Error Occurred
Error Number: 1017
Can't find file: './ci/users.frm' (errno: 13)
SELECT COUNT(*) AS `numrows` FROM (`users`) WHERE `email` = 'admin#localsite.com'
I googled that its permission problem, but don't know what do next.
Log from /var/log/mysql/error.log:
110622 19:27:21 [ERROR] /usr/sbin/mysqld: Can't find file: './ci/users.frm' (errno: 13)
Permissions problem meaning the permissions on the file. MySQL probably can't read it. Just change the owner and group to mysql and it should work.
chown mysql:mysql /var/lib/mysql/ci/*
As well as the files being readable by the MySQL user, the directory containing the .MYI files needs to be read, write and executable by the MySQL user. On my system this was achieved by:
chown -R mysql:mysql /var/lib/mysql/dbname
chmod -R 660 /var/lib/mysql/dbname
chown mysql:mysql /var/lib/mysql/dbname
chmod 700 /var/lib/mysql/dbname
This is an old topic, but I didn't find anything that worked for me so for anyone running into the same problem, yet the above file permission suggestions still don't change the "Can't find file" errors, here's what worked for me and my particular issue.
I was doing a rescue from one CentOS server to another using a recovery image, which had a different OS than the original OS and the original filesystem was mounted on a temporary dir. While I had access to the original /var/lib/mysql files, I didn't have access to the mysql admin or dump utilities, which requires the server to be running anyway (it's not automatically included when doing a recovery from a read-only image). Backups were a week old and I wanted to see if I could get the most recent data possible.
Changing the standard file permissions on these still kept giving "Can't find file" for nearly all of the database tables, however I could see that the tables were there. Turns out it was related to SELinux context on the files I had moved over using rysnc. All of the rescued dirs and files looked like this:
$ ls -alZ
drwx------. mysql mysql unconfined_u:object_r:admin_home_t:s0 somedb_dev
drwx------. mysql mysql unconfined_u:object_r:admin_home_t:s0 somedb_local
drwx------. mysql mysql unconfined_u:object_r:admin_home_t:s0 somedb_production
drwx------. mysql mysql unconfined_u:object_r:admin_home_t:s0 somedb_staging
The -Z flag notes the security context of files and dirs. Notice the unconfined_u and admin_home_t context. These are different from what they should be:
drwx------. mysql mysql system_u:object_r:mysqld_db_t:s0 mysql
Changing these database files to the proper context solved the problem and gave proper access to mysqld using the chcon command:
$ chcon -R -u system_u -t mysqld_db_t somedb_*
This changed all my custom databases to the proper SELinux context and the files could now be recognized by mysqld. I recommend running the chcon commad while the database server is not active, just as a precaution.
Hope that helps someone running into the same problem I had! Of course, you can turn off SELinux temporarily to test if this is fact this issue, but I didn't want turning off SELinux as a permanent solution.
I followed this steps:
Stop the mysql service.
Modify the my.cnf line datadir to my custom location.
Deleted all the files ib_data* , ib_logfile* in our new custom location
Change the permissions of the entire folder with your sentence:
chown mysql:mysql -R /custom_location/mysql/*
Start again the mysql service.
It works!!
Thanks
This error also occurs if the table is not in the database; so if you changed permissions of the directory and are still running into issues check your database and make sure the table is there.
So let's say you got an error like the OP:
Can't find file: './ci/users.frm'
ci is the database name
users is the table name
So in this case if you changed permissions and still had this issue you would verify that the users table is in the ci database.
#Brent Baisley It does work in XAMPP for Linux, but the location is different.
I did upgrade the Kernel today to fix the new Linux “Dirty Cow” Vulnerability (CVE-2016-5195). After the reboot I got the 'frm' permission error too.
So, if you get the following error:
Can't find file: 'yourtablename.frm' (errno: 13 - Permission denied) SQL query :...
You can do:
chown mysql:mysql /opt/lampp/var/mysql/yourDBname/*.frm
This will resolve your issue.
If you'd like to check, if your permission to any of the files has been modified before you execute the permission change, do:
ls -l /opt/lampp/var/mysql/yourDBname/*.frm
Hope that helps someone.
If you have failed RENAME TABLE statement, it could leave MySQL metadata in bad state. The solution is to recreate schema or to recreate table.