I am experiencing some permission problems with my SELECT ... INTO OUTFILE statement.
When I log into my database and do a simple export command, eg:
mysql> select * from XYZ into outfile '/home/mropa/Photos/Desktop/TEST.txt';
I get the respond:
ERROR 1 (HY000):
Can't create/write to file '/home/mropa/Photos/Desktop/TEST.txt'
(Errcode: 13)
However, when I simply write:
mysql> select * from XYZ into outfile 'TEST.txt';
Query OK, 8287 rows affected (0.73 sec)
The file is written into the directory /var/lib/mysql/XYZ.
I looked into the file /etc/apparmor.d/usr.sbin.mysqld where mysql seems to define the reading and writting permissions but I don't really know how to modify it.
How can I give myself permission to export a mysql table into any directory I like?
The issue is directory permissions. mysqld does not run as current_user. Add the mysqld user to the group that has write permissions on your target directories (convenient, but not as secure) or remember to change your target directory permissions before and after you write the outfile.
you can create a directory that is writable by the user that is running mysqld (usually "mysql") and write the file there. For intance:
chmod a+w /home/mropa/mysql
This sounds like you don't have access to that particular folder.
You should add mysql to the group owner of that particular location.
I don't know under what user you are running mysql under, however,
chown mysql:mysql on /home/mropa/Photos/Desktop/logs would mean that mysql user and mysql group is the owner so has permission. You then need to make sure that the permissions include writing but that should be sufficient.
Chown Command
See https://wiki.ubuntu.com/DebuggingApparmor for information on debugging/disabling apparmor profiles.
It may not be an apparmor issue in particular. The user that mysqld is running as may not have permissions to write to the folder you specified. Check the permission on the destination directory/file.
mysql usually runs under user mysqld. permissions may be solved directly with apparmor. see this answer
Related
I'm getting the following exception while trying to start the hive in Ubuntu 14.04 LTS,Caused by: java.sql.SQLException: Failed to create database 'metastore_db', see the next exception for details. Hadoop installation is correct and it's working fine. Please tell me anyone what's problem?
It is because you're not in the same folder where you have created your metadata. I was facing the same problem because I was in my main user folder. When I changed the folder from main user to hduser my hive stated working.
See the mistake
I tried to find the xml file but it was not their so I searched and found where it was.
Similar to #dk14, In my case, I was in a folder on which I had no permission to write as user, moved directory and worked fine.
The reason for above error is, the user through which you are login doesn't have permission to write in that particular directory. I mean the directory in which you are running the schematool command.
For example my setup of Apache Hive was in /opt/apache-hive-3.1.2-bin I ran the command :-
sudo chown -R hadoopusr /opt/apache-hive-3.1.2-bin/
it is happening because you are on the other folder than your hive is installed.
so first of all change directory to the folder where your hive is installed and you and after that try to run hive once again.
and the hive should work properly.
Best of luck.
After spending some(lot) of time I got that issue is with creating that directory metastore_db inside DERBY_HOME/bin path was already there and I didn't had admin access for this you either:
delete that folder by using admin rights.
open hive-site.xml inside HIVE_HOME/conf path open in notepad and check connection string there change the database name to something else, it worked for me.
How can I change the owner of the files written by php from terminal (command line)? The files are created by upload form in apposite folder.
Many thaks
Use the command "chown":
chown owner filenames
To solve this problem in the future uploads, you can use the chown command:
chown($path, $user_name);
http://php.net/manual/en/function.chown.php
There is also a chmod command, if you prefer to change permissions:
http://www.php.net/manual/en/function.chmod.php
Maybe you can change the owner within the PHP program itself (of course if you have the permission to do that) with the exec command of PHP.
For example:
exec('whoami');
See the documentation of this php instruction here: http://php.net/manual/en/function.exec.php
This could work, but only if the servers configuration allows so.
If this doesn't work, you can try also this, but again you need some priviledges to do it:
// File name and username to use
$file_name= "foo.php";
$path = "/home/sites/php.net/public_html/sandbox/" . $file_name ;
$user_name = "root";
// Set the user
chown($path, $user_name);
See the documentation of this php instruction here: http://php.net/manual/en/function.chown.php
There are some instructions in php to modify file attributes like, chmod, chown, among others.
I'm attempting to pipe an email to PHP with my Postfix mail server, using the technique mentioned here and have encountered the following error...
Mar 16 22:52:52 s15438530 postfix/pipe[9259]: AD1632E84C63: to=<php#[myserver].com>, relay=plesk_virtual, delay=0.61, delays=0.59/0/0/0.02, dsn=4.3.0, status=deferred (temporary failure. Command output: /bin/sh: /var/www/vhosts/[myserver].com/httpdocs/clients/emailpipe/email2php.php: Permission denied 4.2.1 Message can not be delivered at this time )
I'd really appreciate if anyone could shed some light on this issue for me. I've tried 777'ing the emailpipe directory, to no avail. Where am I going wrong?
Many thanks.
From the postfix docs...
For security reasons, deliveries to command and file destinations are performed with the rights of the alias database owner. A default userid, default_privs, is used for deliveries to commands/files in root-owned aliases.
So you have two options, either set the default_privs in main.cf to match the ownership of the email2php file.
Alternatively, there should be a way to create an alias database that is owned by the user instead of postfix/nobody. I haven't tried this before though so can't advise.
I have fixed this issue by disabling the SELINUX.
Make sure that you have
#!/usr/bin/php
<?php
(or whatever your path to php is - do "which php" on the server)
at the top of each of your php scripts and that each of the php script files is executable
chmod +x /var/.../email2php.php
Also, make sure that you can test the script from the command line:
cat some_rfc822_email.txt | /var/.../email2php.php
and get the result that you want
To fix this issue, you'll want to chown or chmod /var/www/vhosts/[myserver].com/httpdocs/clients/emailpipe/email2php.php to executable by your postfix user. Alternately, you'll want to redefine this user to execute the file successfully.
Simply changing the permissions of your directory (unless you used -R) won't be sufficient.
To illustrate why this works, consider the following toy example:
<me>#harley:~$ touch test
<me>#harley:~$ ls -al test
-rw-r--r-- 1 <me> <me> 0 2012-03-26 23:44 test
<me>#harley:~$ sh test
<me>#harley:~$
<me>#harley:~$ ./test
bash: ./test: Permission denied
<me>#harley:~$ chmod 755 test
<me>#harley:~$ ./test
<me>#harley:~$
In order to execute a file directly through the running shell, it needs to be set as executable. Other invocations (for example, sh email2php.php or php email2php.php) only require read access, because they're chaining execution off a different file entirely.
For what's likely to be causing the issue in the first place, see here.
I am using the EnterpriseDB pgAdmin III (v. 1.12.1) on a Windows 7, 32-bit machine to work with PostgreSQL databases on a remote Linux server. I am logged in as the user postgres, which allows me to access the $PGDATA directory (in this instance, it is found here: /var/lib/pgsql/data/)
If I log into the server via a terminal, run psql, and use the \copy command to import data from csv files into newly created tables, I have no problems.
If I'm in pgAdmin, however, I use the COPY command to import data from csv files into newly created tables.
COPY table_name FROM '/var/lib/pgsql/data/file.csv'
WITH DELIMITER AS ',' csv header
Sometimes this works fine, other times I get a permissions error:
ERROR: could not open file '/var/lib/pgsql/data/file.csv" for reading: Permission denied
SQL state: 42501
It is the inconsistency of the error that is confusing to me. When the error arises, I change the file permission to anywhere from 644 - 777, with no effect. I also try moving the file to other folders, e.g., var/tmp/, also with no effect.
Any ideas?
The problem is the access permissions trough the directories to the file. Postgres user does not have access to your home folder, for example. The answer is to use a folder all users have access like /tmp, or create one with the correct permissions so any user can access/read/write there, a sort of users shared folder.
I think your postgres user still don't have access to your file.
Did you tried the folowing commands ?
chown postgres /var/lib/pgsql/data/file.csv
chmod u+r /var/lib/pgsql/data/file.csv
Try \COPY table_name FROM '/var/lib/pgsql/data/file.csv'
WITH DELIMITER AS ',' csv header
Notice the backslash before copy, when you run it with back slash it runs with user permissions other wise it just runs as postmaster which in the documentation is deprecated for recent versions of pg :|, anyways this might probably do the trick for ya .
I get the following alert when I run a Ruby script
warning: Insecure world writable dir /Users/cs/Documents in PATH, mode 040777
The solution is to change the permissions. However, I am unsure which one is the appropriate one.
I use many user accounts for different purposes. I have one main account by which I run the commands at my cs -account.
Which permissions would you give for the cs -account?
Just run chmod og-w /Users/cs/Documents and all should be well.
This will remove the "other" and "group" write access permissions.