Could Not Open File For Reading Permission Denied Postgresql
Re: Craig Ringer 2016-08-12 I think we should emit a HINT here, something like: ERROR: could not open file 'D:CBSwoningcijfers2014.csv' for reading: No such file or directory' HINT: Paths for COPY are on the PostgreSQL server, not the client. You may want psql's copy or a driver COPY. FROM STDIN wrapper+1 on the idea.
postgres=# COPY x TO '/root/nopermissions'; ERROR: could not open file '/root/nopermissions' for writing: Permission denied HINT: Paths for COPY are on the PostgreSQL server, not the client. You may want psql's copy or a driver COPY. FROM STDIN wrapperTO STDOUT.Also, I vaguely get what you wanted to say with 'a driver.wrapper', but it's pretty nonsensical if one doesn't know about theprotocol details. I don't have a better suggestion now, but I think itneeds rephrasing.Christoph. Craig Ringer writes: On 12 August 2016 at 16:34, Christoph Berg wrote: Also, I vaguely get what you wanted to say with 'a driver. wrapper', but it's pretty nonsensical if one doesn't know about the protocol details. I don't have a better suggestion now, but I think it needs rephrasing.
I don't like it either, but didn't come up with anything better. The problem is that every driver calls it something different.A few thoughts on this patch:1. I don't really think the HINT is appropriate for the not-absolute-pathcase.2. I don't think it's appropriate for all possible cases of AllocateFilefailure either, eg surely not for EACCES or similar situations where wedid find a file. Maybe print it only for ENOENT? (See for examplereportnewlocalefailure for technique.)3. As for the wording, maybe you could do it like this:HINT: COPY copies tofrom a file on the PostgreSQL server, not on theclient.
You may want a client-side facility such as psql's copy.That avoids trying to invent a name for other implementations.regards, tom lane. On 2 September 2016 at 04:28, Tom Lane wrote: Craig Ringer writes: On 12 August 2016 at 16:34, Christoph Berg wrote: Also, I vaguely get what you wanted to say with 'a driver. wrapper', but it's pretty nonsensical if one doesn't know about the protocol details. I don't have a better suggestion now, but I think it needs rephrasing. I don't like it either, but didn't come up with anything better.
The problem is that every driver calls it something different. A few thoughts on this patch:Thanks for the review. I'll leave the first change pending yourcomments, the others are made, though I'm not completely sure weshould restrict it to ENOENT. 1. I don't really think the HINT is appropriate for the not-absolute-path case.Why? If the user runs# COPY sometable FROM 'localfile.csv' WITH (FORMAT CSV);ERROR: could not open file 'localfile.csv' for reading: No such fileor directorythey're going to be just as confused by this error as by:# COPY batchdemo FROM '/tmp/localfile.csv' WITH (FORMAT CSV);ERROR: could not open file '/tmp/localfile.csv' for reading: No suchfile or directoryso I don't really see the rationale for this change. 2.
I don't think it's appropriate for all possible cases of AllocateFile failure either, eg surely not for EACCES or similar situations where we did find a file. Maybe print it only for ENOENT? (See for example reportnewlocalefailure for technique.)I thought about that but figured it didn't really matter too much,when thinking about examples like# COPY batchdemo FROM '/root/secret.csv' WITH (FORMAT CSV);ERROR: could not open file '/root/secret.csv' for reading: Permission deniedor whatever, where the user doesn't understand why they can't read thefile given that their local client has permission to do so.I don't feel strongly about this and think that the error on ENOENT isby far the most important, so I'll adjust it per your recommendation.
Ezswitchsetup switch manager. In addition, enhanced Brocade ISL Trunking enables a single logical high-speed trunk capable of up to 68 Gbit/sec of throughput. Simplified ManagementBrocade 300 setup and configuration is simplified with the Brocade EZSwitchSetup wizard, which makes switch configuration, deployment, and management an easy 3-step point-and-click process. The Brocade 300 provides these capabilities while consuming less than 2.5 watts of power per port for exceptional power and cooling efficiency.The Brocade 300 features a non-blocking architecture with as many as 24 ports concurrently active at 8 Gbit/sec (full duplex) with no over-subscription providing an aggregate bandwidth of 408 Gbit/sec. To manage Brocade switches, organizations can use a command line interface, the Brocade Web Tools utility, EZSwitchSetup, Switch Manager, or SAN management tools such as Brocade EFCM and Fabric Manager. The Brocade 300, which is Microsoft Simple SAN-compatible, also supports a USB port that increases serviceability and error logging by facilitating firmware upgrades and downloads of system log files.
3. As for the wording, maybe you could do it like this: HINT: COPY copies tofrom a file on the PostgreSQL server, not on the client. You may want a client-side facility such as psql's copy. That avoids trying to invent a name for other implementations.I like that wording a lot more, thanks.
Adopted.-Craig Ringer Development, 24x7 Support, Training & Services. Craig Ringer writes: On 2 September 2016 at 04:28, Tom Lane wrote: 1. I don't really think the HINT is appropriate for the not-absolute-path case.
Why? I wrote: Craig Ringer writes: I thought about that but figured it didn't really matter too much, when thinking about examples like # COPY batchdemo FROM '/root/secret.csv' WITH (FORMAT CSV); ERROR: could not open file '/root/secret.csv' for reading: Permission denied or whatever, where the user doesn't understand why they can't read the file given that their local client has permission to do so. Meh. Hinting in this case could be helpful only if the user in fact had identical directory structures on client and server and a data file in the right place on both.So my consciousness was raised just now by an example of exactly thisscenario over in pgsql-novice.
What I forgot was that the client mayin fact be on the same machine as the server, in which case EACCESis pretty much exactly what you'd expect. So we probably do want tohint for that case, but the hint wording I previously suggested nolonger seems like le mot juste. It needs to cover the idea thatthe client and server are different processes on the same machine.I don't suppose there's any easy way for COPY to distinguish localfrom remote connections - if it could, that might influence boththe errnos to hint for and the phrasing of the hint.regards, tom lane. On 4 September 2016 at 23:33, Tom Lane wrote: So my consciousness was raised just now by an example of exactly this scenario over in pgsql-novice. What I forgot was that the client may in fact be on the same machine as the server, in which case EACCES is pretty much exactly what you'd expect.Yep. Also in cases with common paths, like /root or whatever. So we probably do want to hint for that case, but the hint wording I previously suggested no longer seems like le mot juste.
It needs to cover the idea that the client and server are different processes on the same machine.Yeah, may be.We. know that in this case 'client' and 'server' stillapplies since client and server can be on the same host, but thepeople who needs this hint may not understand that. Though there'sonly so much we can do or should try to do in a HINT.I think the most important bit is pointing them at copy, so it's still useful.To cover the same-host case we could try something like:COPY runs on the PostgreSQL server, using the PostgreSQL server'sdirectories and permissions, it doesn't run on the client. But I think that's actually less helpful for the users who'll need this.We could say 'COPY runs as the PostgreSQL server' but that's the kindof hint that mostly helps people who already understand it and don'tactually the hint.(BTW, whoever came up with 'EACCES' needs to go spend time with thecreat system call somewhere dark and smelly).
I don't suppose there's any easy way for COPY to distinguish local from remote connectionsNot that I see, since 'local' can be unix socket or tcp to localhost.Not cleanly anyway.I don't think it matters. Many hosts have enough paths in common thatin practice the hint on EACCES will be useful anyway. It'd be nice towork in something about running with the permissions of the PostgreSQLserver, but I don't see a way to do that without making it all morecomplex.I don't think it's worth tons of time anyway. This will be better thanwhat we have, lets do it.I'm fairly happy with the wording you came up with:'COPY copies to a file on the PostgreSQL server, not on the client. 'You may want a client-side facility such as psql's copy.'
And am inclined to suggest going ahead with the existing wording. Iagree that removing the part for 'relative path not allowed for COPYto file' is reasonable, so I've attached an update that does so andwarns on EACCES too.-Craig Ringer Development, 24x7 Support, Training & Services.
Re: Craig Ringer 2016-09-05 To cover the same-host case we could try something like: COPY runs on the PostgreSQL server, using the PostgreSQL server's directories and permissions, it doesn't run on the client. But I think that's actually less helpful for the users who'll need this.The part about the server permissions might be useful to hint at. I don't suppose there's any easy way for COPY to distinguish local from remote connections Not that I see, since 'local' can be unix socket or tcp to localhost. Not cleanly anyway. I don't think it matters. Many hosts have enough paths in common that in practice the hint on EACCES will be useful anyway. It'd be nice to work in something about running with the permissions of the PostgreSQL server, but I don't see a way to do that without making it all more complex.
I don't think it's worth tons of time anyway. This will be better than what we have, lets do it.It's probably not helpful trying to distinguish local and remoteconnections, the set of possible problems is diverse and this is justone of them. I'm fairly happy with the wording you came up with: 'COPY copies to a file on the PostgreSQL server, not on the client. ' 'You may want a client-side facility such as psql's copy.' What about'COPY TO instructs the PostgreSQL server to write to a file on the server.
' 'You may want a client-sidefacilitysuch as psql's copy.' 'COPY FROM instructs the PostgreSQL server to read from a file on the server. ' 'You may want a client-sidefacilitysuch as psql's copy.'
This stresses more explicitly that the file is opened by the serverprocess. (I'm not particularly happy that it says 'server' in theretwice, but couldn't think of anything else.)Christoph. On 5 September 2016 at 16:32, Christoph Berg wrote: The part about the server permissions might be useful to hint at. What about 'COPY TO instructs the PostgreSQL server to write to a file on the server.
' 'You may want a client-side facility such as psql's copy.' 'COPY FROM instructs the PostgreSQL server to read from a file on the server. ' 'You may want a client-side facility such as psql's copy.' This stresses more explicitly that the file is opened by the server process. (I'm not particularly happy that it says 'server' in there twice, but couldn't think of anything else.)Tom, any preference here?I'm probably inclined to go for your original wording and accept thatit's just too hard to hint at the client/server process split in asingle short message.- Craig Ringer Development, 24x7 Support, Training & Services.
Craig Ringer writes: Tom, any preference here? I'm probably inclined to go for your original wording and accept that it's just too hard to hint at the client/server process split in a single short message.I think my original wording is pretty hopeless for the single-machinecase: 'COPY copies to a file on the PostgreSQL server, not on the client'.If the server and client are the same machine, that's content-free.Christoph's idea isn't bad. We could tweak it to:COPY TO instructs the PostgreSQL server process to write a file.COPY FROM instructs the PostgreSQL server process to read a file.This seems to cover both the wrong-machine and wrong-process-identitycases, and as a bonus it might help if you've had a brain fade aboutwhich COPY direction is write vs.
Read.(I think we're all in agreement that the second sentence of the hintis fine, so leaving that out of it.)Comments?regards, tom lane. Re: Tom Lane 2016-09-06 Christoph's idea isn't bad. We could tweak it to: COPY TO instructs the PostgreSQL server process to write a file.
Could Not Open File For Reading Permission Denied Postgres
COPY FROM instructs the PostgreSQL server process to read a file. This seems to cover both the wrong-machine and wrong-process-identity cases, and as a bonus it might help if you've had a brain fade about which COPY direction is write vs. Read. (I think we're all in agreement that the second sentence of the hint is fine, so leaving that out of it.) Comments?I like your new version, it's crisp and transports the right message.Christoph.