MacOS Postgres 10 can't read csv file - postgresql

I'm trying to copy a CSV file into a table by running a simple \copy command in Postgres;
postgres-# \copy solved_at FROM '/Users/funnychef/Downloads/export.csv' DELIMITER AS ',';
Every time I run the command I receive the Permission Denied error:
/Users/funnychef/Downloads/export.csv: Permission denied
The permissions on the file are wide open;
$ ls -ltr ~/Downloads/expor.csv
-rwxrwxrwx 1 funnychef staff 145524 Jul 8 22:15 /Users/funnychef/Downloads/export.csv
I assumed that the issue was related to the _postgres user not having access to the file so I made that user the owner of the file but still receive the error.
$ ls -ltr ~/Downloads/expor.csv
-rwxrwxrwx 1 _postgres staff 145524 Jul 8 22:15 /Users/funnychef/Downloads/export.csv
What am I missing?

Copy your file to /tmp directory and read the csv. The normal settings for /tmp are 1777, which ls shows as drwxrwxrwt

Related

Create empty directories with cloud_init

I am trying to configure an user account using one cloud-init yaml file that include a call to write_files module, like this:
write_files:
#passwd file for vncserver
- path: /home/ubuntu/.vnc/passwd
owner: ubuntu:ubuntu
permissions: '0600'
defer: true
encoding: b64
content: bmtzZGN1eQo=
The file is created as expected, but the problem is that the parent directory is owned by root, and not by ubuntu user.
$ ls -la .vnc/
total 12
drwxr-xr-x 2 root root 4096 Dec 20 16:24 .
drwxr-x--- 5 ubuntu ubuntu 4096 Dec 20 16:24 ..
-rw------- 1 ubuntu ubuntu 8 Dec 20 16:24 passwd
I tried to manually create the /home/ubuntu/.vnc/ directory prior to create the passwd file to be able to set the ownership of the directory, just to find that documentation of write_files does not explain how to create (empty) directories.
I know that I could do this using runcmd module to insert a command like this:
runcmd:
- mkdir --mode 0600 --parents /home/ubuntu/.vnc
- echo bmtzZGN1eQo | base64 -d > /home/ubuntu/.vnc/passwd
- chmod 0600 /home/ubuntu/.vnc/passwd
but this seems to be too complex to do such small task.
It is possible to use write_files module to create directories or change ownership/permission of existing directories?

Permission denied for COPY file on valid directory

My PostgreSQL v10 is running on a UBUNTU server. The user group www-data contains the user postgres, as checked by grep ^www-data /etc/group. When I do sudo chown -R :postgres MyPath it works fine, but when I change to sudo chown -R :www-data MyPath it not works.
How to set permissions for postgres user access other user group?
NOTES
As #LaurenzAlbe suggested on comment, the ls -ld myPath is drwxrwxr-x 29 root postgres 4096 Feb 27 15:54 myPath
and id postgres is uid=112(postgres) gid=117(postgres) groups=117(postgres),33(www-data),116(ssl-cert)

`pg_ls_dir` can query some directories, but not others

On my system, /home and /etc have exactly the same permissions:
$ ls -ld /home /etc
drwxr-xr-x 67 root root 4096 Nov 13 15:59 /etc
drwxr-xr-x 3 root root 4096 Oct 18 13:45 /home
However, Postgres can read one, but not the other:
test=# select count(*) from (select pg_ls_dir('/etc')) a;
count
-------
149
(1 row)
test=# select count(*) from (select pg_ls_dir('/home')) a;
ERROR: could not open directory "/home": Permission denied
Even though the user the DB is running as can, in fact, run ls /home:
$ sudo -u postgres ls /home > /dev/null && echo "ls succeeded"
ls succeeded
What is going on?
My postgres version is 11.5, running on Arch Linux.
I figured it out, it is because Arch's bundled postgresql.service file set ProtectHome=true, causing systemd to use Linux mount namespaces to block the postgres processes from accessing /home.

Problems with permissions for logrotate

I'm writing my own logrotate configuration for some web application:
/home/me/public_html/logs/*.log {
daily
missingok
rotate 15
compress
delaycompress
notifempty
create 0660 me www-data
nosharedscripts
}
But running logrotate for these files results in:
$ sudo logrotate -d -v *.log
Ignoring logfile1.log because of bad file mode.
Ignoring logfile2.log because of bad file mode.
Ignoring otherlogfile.log because of bad file mode.
Handling 0 logs
$ ls -l
-rw-rw---- 1 me www-data 893584 Jan 27 16:01 logfile1.log
-rw-rw---- 1 me www-data 395011 Jan 27 16:01 logfile2.log
-rw-rw---- 1 me www-data 4949115 Jan 27 16:01 otherlogfile.log
Is this related to the file permissions of the actual logfiles in the directory of to the permissions specified with create 0660 me www-data?
If I change the filepermissions to -rw-r----- and the create line to
create 0640 me www-data
I get
$ sudo logrotate -d -v *.log
Ignoring logfile1.log because the file owner is wrong (should be root).
Ignoring logfile2.log because the file owner is wrong (should be root).
Ignoring otherlogfile.log because the file owner is wrong (should be root).
Handling 0 logs
My system is a debian testing/jessie.
Ok, stupid situation. The logrotate command has to be executed on the configuration file instead of the log file.
$ sudo logrotate -d -v /etc/logrotate.d/my-app
It seems to be important that the parent directory of the logfile is not world writable (------rw-) and not writable by any non root group (---rw----). Otherwise, you will see:
error: skipping "/home/me/public_html/logs/logfile1.log" because parent
directory has insecure permissions (It's world writable or writable by
group which is not "root") Set "su" directive in config file to tell
logrotate which user/group should be used for rotation.

Cannot remove file or Directory

I have root on the server in question.
OS: Solaris 10 sparc
When I ls the audit_old directory I get:
root#z10801 audit_old # ls
qm2_ora_24871_1c.aud.gz
ls -al results in:
root#z10801 audit_old # ls -al
total 250658
drwxr-x--- 2 oraqm2 dba 128261632 Mar 6 21:55 .
drwxr-x--- 17 oraqm2 dba 512 Mar 6 20:55 ..
rm gives me:
root#z10801 audit_old # rm qm2_ora_24871_1c.aud.gz
qm2_ora_24871_1c.aud.gz: No such file or directory
rm -rf the dir gives me:
root#z10801 rdbms # rm -rf audit_old/
rm: Unable to remove directory audit_old/: File exists
Any help would be great!
Thanks!
This behavior may be due to a file currently open by a separate process.
Even though you have removed it, the file is not truly removed by the OS until the process closes the file.
Try to find out the process that has the file open by using:
$ fuser .
In the directory which has the problem.
This command will print the process Id's which have files currently in use.