My goal is to import csv file to postgresql database.
my file is located in network shared folder and I do not have no option to make it in a local folder.
My Folder located in :
"smb://file-srv/doc/myfile.csv"
When I run my this PostgreSQL script:
COPY tbl_data
FROM 'smb://file-srv/doc/myfile.csv' DELIMITER ',' CSV;
I would get this error :
ERROR: could not open file "smb://file-srv/doc/myfile.csv" for reading: No such file or directory
SQL state: 58P01
I have no problem to access the file and open it.
I am using PostgreSQL 9.6 under Ubuntu 16.04.
Please Advice how to fix this problem.
Update
When I try to access the file with postgres user I would have same error:
postgres#file-srv:~$$ cat smb://file-srv/doc/myfile.csv
cat: 'smb://file-srv/doc/myfile.csv' : No such file or directory
As I mention when I user mounted folder I created I can access the file.
it is about permission. you have to check read access on file and folders.
also, logging with superuser access may solve your problem.
In short, this is a permissions issue: Your network share is likely locally mounted to your user's UID, while the PostgreSQL server is running as the postgres user.
Second, when you log into your database, there is not an overlap between the database's users and the system's users, even if you have the same username. This means that when you request a file from your network share, the DB user, in this case postgres, does not have the necessary permissions.
To see this, and assuming you have root access on the box in question, you might try to become the postgres user and see that you cannot access the file:
$ sudo su - postgres
$ cat /run/user/.../smb.../yourfile.csv
Permission denied
The fix to your issue will involve -- somehow -- making the file or share accessible to the postgres user. Copying is certainly the quickest way. But that's off the table. You could mount the share (perhaps as read only) as the postgres user. You might do this in fstab.
However, unless this is going to be an automated detail that happens regularly, this seems like heroics. Without more information as to why you can't copy locally, I suggest copying the file locally.
Related
I am trying to export my Postgres table to a csv on my desktop and I get this error:
ERROR: could not open file "C:\Users\blah\Desktop\countyreport.csv" for writing: Permission denied
SQL state: 42501
This is my query which I believe is the correct syntax
COPY countyreport TO 'C:\\Users\\blah\\Desktop\\countyreport.csv' DELIMITER ',' CSV HEADER;
According to the user manual:
Files named in a COPY command are read or written directly by the
server, not by the client application.
https://www.postgresql.org/docs/current/static/sql-copy.html
The common mistake is to believe that the filesystem access will be that of the (client) user, but it's not. It's normal to run the postgresql server as its own user. Therefore action carried out by the server will be done as a different OS user to the client. The server is usually run as an OS user postgres.
Assuming that you are running the server on your local machine then the simplest way to fix it would be to give postgres access to your home directory or desktop. This can be done by changing the windows security settings on your home directory.
Before you do this.... Stop and think. Is this what you are looking for? If the server is in development then will it always run on the user's machine. If not then you may need to use COPY to write to the stdout. See the manual for information on this.
Following my previous question I'm now trying to execute a batch file trough NSIS code in order to successfully setup the postgres installation after it is being unzipped. The batch file contains command for initializing the database but it fails because of permission restrictions. I am on a Win7 x64 PC. My user account is the administrator and I start the Setup.exe with Run as adminitrator option. This is the error I get:
C:\Program Files (x86)\Poker Assistant>cd "pgsql\bin"
C:\Program Files (x86)\Poker Assistant\pgsql\bin>initdb -U postgres -A
password
--pwfile "pwd.txt" -E utf8 -D "..\data" The files belonging to this database system will be owned by user "Mandarinite".
This user must also own the server process.
The database cluster will be initialized with locale
"Bulgarian_Bulgaria.1251". initdb: could not find suitable text search
configuration for locale "Bulgarian_ Bulgaria.1251" The default text
search configuration will be set to "simple".
Data page checksums are disabled.
creating directory ../data ... initdb: could not create directory
"../data": Permission denied
EDIT: After tinkering little more with the installer I got to the root of the problem. I cannot in any way execute the following command when the installation is in the Program Files folder:
initdb -U postgres -A password --pwfile "pwd.txt" -E utf8 -D "..\data"
I tried from .bat file. I tried from .cmd file. I tried manually from Command Prompt. I tried start as Administrator. All attempts resulted in the Permission denied error
EDIT2: I did not find any way to fix the problem so I made a workaround. Now I distribute the postgres with its data directory already initialized. Then I only need to create the service and start it.
I just realised what the issue here is.
If you run postgres as Administrator, it uses a special Windows API call to drop permissions (acquire a restricted token), so that it runs without full Administrator rights for security. See PostgreSQL utilities and restricted tokens on windows.
I suspect that what's happening here is that initdb isn't creating the target data directory and setting its permissions before doing that, so it drops permissions and then doesn't have the permissions to create the data directory.
To work around it, simply md ..\data to create the empty directory and then use icacls.exe to grant appropriate permissions before you try to initdb. Or, even better, store it in a more appropriate place like %PROGRAMDATA%\MyApp\pgdata or whatever; application data should not go in %PROGRAMFILES%.
I am using PostgreSQL and Centos
While in the the task database I am trying to do this
COPY CUSTOMERS TO '/home/cjones/cfolder/customers.txt' (DELIMITER '|');
I am getting the
Error: could not open file "/home/cjones/customers.txt" for writing: Permission denied
I have done ls -al and chmod the customers.txt to 777 and still getting this error. Any ideas?
Are you aware of all requirements? Per documentation:
1.
You must have select privilege on the table whose values are read by
COPY TO
2.
COPY naming a file or command is only allowed to database superusers,
since it allows reading or writing any file that the server has
privileges to access.
Plus, for the file to be accessible by the server it must lie on the same machine of course. And the directory must be accessible to the user the postgres server runs as, typically postgres (not only the file).
An alternative would be to use the \copy meta-command of psql.
This question already has answers here:
Postgres ERROR: could not open file for reading: Permission denied
(17 answers)
Closed 9 years ago.
How do you copy data from a file to a table in SQL? I'm using pgAdmin3 on a Macbook.
The table name is tutor, and the name of the file is tutor.rtf.
I use the following query:
COPY tutor
FROM /Users/.../tutor.rtf
WITH DELIMITER ',';
but got the error "permission denied'.
The file is not locked. So how do you solve this problem? Or is there any other quicker way to copy data from file to table except for INSERT INTO ... VALUE(); ?
COPY opens the file using the PostgreSQL server backend, so it requires that the user postgresql runs as have read permission (for COPY FROM) for the file in question. It also requires the same SQL-level access rights to the table as INSERT, but I suspect it's file permissions that're getting you here.
Most likely the postgres or postgres_ (depending on how you installed PostgreSQL) user doesn't have read access to /Users/somepath/tutor.rtf or some parent directory of that file.
The easiest solution is to use psql's \copy command, which reads the file using the client permissions, rather than those of the server, and uses a path relative to the client's current working directory. This command is not available in PgAdmin-III.
Newer PgAdmin-III versions have the Import command in the table context menu. See importing tables from file in the PgAdmin-III docs. This does the equivalent of psql's \copy command, reading the file with the access rights of the PgAdmin-III application.
Alternately you can use the server-side COPY command by making sure every directory from /Users up somepath has world-execute rights - meaning users can traverse it, cd into it, etc, but can't list its contents without r rights too. Then either set the file to group postgres and make sure it has group read rights, or make it world-readable.
I know this issue has already been raised by others, but even trying previous suggestions I still get this error...
When I try to populate a table copying from a csv file, I get a permission error.
COPY Eurasia FROM '/Users/Oritteropus/Desktop/eurasia1.csv' CSV HEADER;
ERROR: could not open file "/Users/Oritteropus/Desktop/eurasia1.csv" for reading: Permission denied
SQL state: 42501
As previously suggested in these cases, I changed the permission of the file (chmod 711 eurasia1.csv or chmod a+r eurasia1.csv) and I also changed the user rights with:
ALTER USER postgres WITH SUPERUSER; #where postgres is my user
However, I still get the same error.
I also tried to manually change the privileges from pgAdmin but seems avery privilege is already given.
I'm working on a Mac Os and I'm using PostGreSQL 9.2.4.
Any suggestion? Thanks
The best option is to change and use COPY FROM STDIN as that avoids quite a number of permissions issues.
Alternatively you can make sure that the postgres user can access the file. This rarely better than COPY FROM STDIN however for a couple reasons.
COPY TO STDOUT can conceivably corrupt your data. Because this involves file I/O by PostgreSQL if bugs exist in COPY FROM STDIN that could be a problem too.
If you are doing it on the server side because of automation/stored proc concerns, this is rarely a win, as you are combining transactional and non-transactional effects. COPY TO STDOUT and COPY FROM STDIN do not have these issues. (For example, you don't have to wonder whether the atime of the inode actually means the file was properly processed).