Thread: Window2012R2: initdb error: "The current directory is invalid."

Hi all,

I have failed in execute initdb in "c:\Windows\Temp\dir" folder as
reproduce logs below. The OS's messages "The current directory is invalid."
was returned.

I think it is a specification of Window2012R2 (because i could not reproduce
In Windows 7) but not PostgreSQL's problem.
But is it need to be do something in PostgreSQL sir?

I found that the ERROR messages produced when bootstrap_template1 (initdb.c)
execute PG_CMD_OPEN (_popen function).
_popen not failed but OS produced "The current directory is invalid." message,
postgres did not start, and _pclose is returned with 1 make initdb failed.

May be, Window2012R2 does not permit to execute postgres command with
none privilege permission in this case, I think so.

--- Reproduce Environment ---
OS: Window2012R2
PostgreSQL: 9.5
Command: initdb
Execute User: Administrator
Execute folder: c:\Windows\Temp\dir
-------------------

--- Reproduce log ---
c:\Windows\Temp>mkdir dir
c:\Windows\Temp>cd dir
c:\Windows\Temp\dir>
c:\Windows\Temp\dir>cmd /c ""C:\Program Files\PostgreSQL\9.5\bin\initdb" --locale=C -D "c:\testdb" -d -n"
Running in debug mode.
Running in noclean mode.  Mistakes will not be cleaned up.
Running in debug mode.
Running in noclean mode.  Mistakes will not be cleaned up.
The files belonging to this database system will be owned by user "Administrator".
This user must also own the server process.

VERSION=9.5.0
PGDATA=c:/testdb
share_path=C:/Program Files/PostgreSQL/9.5/share
PGPATH=C:/Program Files/PostgreSQL/9.5/bin
POSTGRES_SUPERUSERNAME=Administrator
POSTGRES_BKI=C:/Program Files/PostgreSQL/9.5/share/postgres.bki
POSTGRES_DESCR=C:/Program Files/PostgreSQL/9.5/share/postgres.description
POSTGRES_SHDESCR=C:/Program Files/PostgreSQL/9.5/share/postgres.shdescription
POSTGRESQL_CONF_SAMPLE=C:/Program Files/PostgreSQL/9.5/share/postgresql.conf.sample
PG_HBA_SAMPLE=C:/Program Files/PostgreSQL/9.5/share/pg_hba.conf.sample
PG_IDENT_SAMPLE=C:/Program Files/PostgreSQL/9.5/share/pg_ident.conf.sample
The database cluster will be initialized with locale "C".
The default database encoding has accordingly been set to "SQL_ASCII".
The default text search configuration will be set to "english".

Data page checksums are disabled.

creating directory c:/testdb ... ok
creating subdirectories ... ok
selecting default max_connections ... 10
selecting default shared_buffers ... 400kB
selecting dynamic shared memory implementation ... windows
creating configuration files ... ok
creating template1 database in c:/testdb/base/1 ... The current directory is invalid.
child process exited with exit code 1
initdb: data directory "c:/testdb" not removed at user's request

c:\Windows\Temp\dir>
---

Best regards,
Dang Minh Huong
NEC Solution Innovators, Ltd.
http://www.nec-solutioninnovators.co.jp/en/

Huong Dangminh schrieb am 19.01.2016 um 11:49:
> I have failed in execute initdb in "c:\Windows\Temp\dir" folder as
> reproduce logs below. The OS's messages "The current directory is invalid."
> was returned.

c:\Windows has special protection and it is not really surprising that a
regular user isn't allowed to write into that directory.

When Postgres is started it drops all "Administrator" privileges
for security reasons (older versions would refuse to start as
Administrator) - and I think initdb is doing the same thing.
So it's understandable that it can't write to c:\Windows

Putting application data into c:\Windows (or "c:\Program Files" for that matter)
is an extremely bad idea to begin with (c:\Windows being even worse than "c:\Program Files")

You shouldn't be doing that anyway.

Thomas

Hi,

Thanks for reply sir,

> -----Original Message-----
> From: pgsql-bugs-owner@postgresql.org [mailto:pgsql-bugs-
> owner@postgresql.org] On Behalf Of Thomas Kellerer
> Sent: 19 Tha=CC=81ng Gi=C3=AAng 2016 9:08 CH
> To: pgsql-bugs@postgresql.org
> Subject: Re: [BUGS] Window2012R2: initdb error: "The current directory =
is
> invalid."
>=20
> Huong Dangminh schrieb am 19.01.2016 um 11:49:
> > I have failed in execute initdb in "c:\Windows\Temp\dir" folder as
> > reproduce logs below. The OS's messages "The current directory is =
invalid."
> > was returned.
>=20
> c:\Windows has special protection and it is not really surprising that =
a regular
> user isn't allowed to write into that directory.
>=20
> When Postgres is started it drops all "Administrator" privileges for =
security
> reasons (older versions would refuse to start as
> Administrator) - and I think initdb is doing the same thing.
> So it's understandable that it can't write to c:\Windows
>=20

I did not mean, create data cluster in C drive made that error sir.
This issue reproduce in all drive specified in -D option.
# My reproduce environment is only one (C) drive. So, sorry for the log.

I mean, it happen when current directory of command line is =
"c:\Windows\Temp\something".
It is rare case, and may be a Windows2012's specification, but i don't =
know
why only "c:\Windows\Temp\something" and are there another case like =
that?

> Putting application data into c:\Windows (or "c:\Program Files" for =
that
> matter) is an extremely bad idea to begin with (c:\Windows being even
> worse than "c:\Program Files")
>=20
> You shouldn't be doing that anyway.
>=20
> Thomas
>=20

Thanks and best regards,
bocap.

>=20
>=20
> --
> Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make
> changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-bugs
>=20
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2016.0.7303 / Virus Database: 4489/11436 - Release Date: =
01/19/16

SGksDQoNClRoYW5rcyBmb3IgcmVwbHkgc2lyLA0KDQo+IA0KPiBPbiAxOSBKYW51YXJ5IDIwMTYg
YXQgMTg6NDksIEh1b25nIERhbmdtaW5oIDxodW8tZGFuZ21pbmhAeXMuanAubmVjLmNvbQ0KPiA8
bWFpbHRvOmh1by1kYW5nbWluaEB5cy5qcC5uZWMuY29tPiA+IHdyb3RlOg0KPiANCj4gDQo+IAlI
aSBhbGwsDQo+IA0KPiAJSSBoYXZlIGZhaWxlZCBpbiBleGVjdXRlIGluaXRkYiBpbiAiYzpcV2lu
ZG93c1xUZW1wXGRpciIgZm9sZGVyDQo+IGFzDQo+IAlyZXByb2R1Y2UgbG9ncyBiZWxvdy4gVGhl
IE9TJ3MgbWVzc2FnZXMgIlRoZSBjdXJyZW50IGRpcmVjdG9yeSBpcw0KPiBpbnZhbGlkLiINCj4g
CXdhcyByZXR1cm5lZC4NCj4gDQo+IA0KPiANCj4gSXMgdGhhdCBkaXJlY3Rvcnkgb3IgYW55IHBh
cmVudCBvZiBpdCBhIGp1bmN0aW9uIHBvaW50Pw0KPiANCj4gaHR0cDovL3d3dy5uaXJzb2Z0Lm5l
dC91dGlscy9udGZzX2xpbmtzX3ZpZXcuaHRtbA0KPiANCj4gDQo+IGh0dHA6Ly9zdXBlcnVzZXIu
Y29tL3EvODIzOTU5DQo+IA0KPiANCg0KTm8sIHNpci4gQXMgbXkgY29uZmlybWVkIHJlc3VsdHMg
YmVsb3cuDQoNCi0tLQ0KYzpcPmRpciBjOlxXaW5kb3dzIHwgZmluZCAiVGVtcCINCjIwMTYvMDEv
MDggIDExOjU1ICAgIDxESVI+ICAgICAgICAgIENic1RlbXANCjIwMTYvMDEvMjAgIDEzOjEwICAg
IDxESVI+ICAgICAgICAgIFRlbXANCg0KYzpcPmRpciBjOlxXaW5kb3dzXHRlbXBcIHwgZmluZCAi
ZGlyIg0KMjAxNi8wMS8xOSAgMTg6NTUgICAgPERJUj4gICAgICAgICAgZGlyDQoNCmM6XD4NCi0t
LQ0KDQo+IEFsc28sIHdoeSB3b3VsZCB5b3UgcG9zc2libHkgcnVuIHRoZSBpbnN0YWxsZXIgZnJv
bSB0aGVyZT8gWW91IHNob3VsZCBiZQ0KPiB1c2luZyAlVEVNUCUgd2hpY2ggc2hvdWxkIGdlbmVy
YWxseSByZXNvbHZlIHRvDQo+IEM6XFVzZXJzXHtVc2VybmFtZX1cQXBwRGF0YVxMb2NhbFxUZW1w
IG9yIHNpbWlsYXIuDQo+IA0KDQpZZXMsIEkgdGhpbmsgaXQgc2hvdWxkIGJlICVVU0VSUFJPRklM
RSVcQXBwRGF0YVxMb2NhbFxUZW1wIA0KKHdlIHNwZWNpZmllZCAlVEVNUCUgb3IgJVRNUCUgd2hl
biBjcmVhdGUgaW5zdGFsbGVyKS4NCkJ1dCBpbiBvbmUgb2YgbXkgY3VzdG9tZXIncyBlbnZpcm9u
bWVudCwgaXQgYmVjYW1lICAiYzpcV2luZG93c1xUZW1wXCAiLg0KDQo+IA0KPiAJY3JlYXRpbmcg
dGVtcGxhdGUxIGRhdGFiYXNlIGluIGM6L3Rlc3RkYi9iYXNlLzEgLi4uIFRoZSBjdXJyZW50DQo+
IGRpcmVjdG9yeSBpcyBpbnZhbGlkLg0KPiANCj4gDQo+IEl0IGxvb2tzIGxpa2Ugc29tZWhvdyB0
aGUgY3VycmVudCB3b3JraW5nIGRpcmVjdG9yeSBpcyB1bm1hcHBlZCBvciBjYW5ub3QNCj4gYmUg
Zm91bmQuDQo+IA0KPiBJcyB0aGVyZSBhbnkgY2hhbmNlIHlvdSBoYXZlIG1hcHBlZCBuZXR3b3Jr
IGRyaXZlcyBpbiB1c2U/DQo+IA0KDQpObyBzaXIsIEkgaGF2ZSBvbmx5IG9uZSBkcml2ZSAoQykg
aW4gcmVwcm9kdWNlIGVudmlyb25tZW50Lg0KDQpJIGhhdmUgdGVzdGVkIHNvbWUgbW9yZSBjYXNl
IGFuZCBmb3VuZCB0aGF0LA0KSW4gV2luZG93czIwMTIsIGV4ZWN1dGUgc29tZSBjb21tYW5kIGlu
IGZvbGRlciB3aGljaCBpcyBzdWJvcmRpbmF0ZQ0Kb2YgIkM6XFdpbmRvd3NcVEVNUFwiIHdpdGgg
dXNlciB0aGF0IGluc3VmZmljaWVudCBwZXJtaXNzaW9uIHRvIA0KYWNjZXNzIHRoYXQgZm9sZGVy
IHdpbGwgcHJvZHVjZSB0aGlzIGVycm9yLg0KDQppbml0ZGIgd2FzIGV4ZWN1dGVkIHdpdGggIkFk
bWluaXN0cmF0b3IiIHByaXZpbGVnZXMsIGJ1dCANCnRoZW4gaW5pdGRiIGRvIHBvcGVuKCkgd2l0
aCBub25lICJBZG1pbmlzdHJhdG9yIiBwcml2aWxlZ2VzDQooYnkgY2hpbGQgcHJvY2VzcykuIA0K
Q2hpbGQgcHJvY2VzcyBub3QgaGF2ZSBlbm91Z2ggcHJpdmlsZWdlcyB0byBhY2Nlc3MgdG8gDQpD
dXJyZW50IGZvbGRlciAoImM6XFdpbmRvd3NcVGVtcFxkaXIiKSwgc28gdGhlDQoiVGhlIGN1cnJl
bnQgZGlyZWN0b3J5IGlzIGludmFsaWQuIiBtZXNzYWdlIHdhcyBwcm9kdWNlZC4NCg0KSSBmb3Vu
ZCB0aGlzIHBoZW5vbWVub24gb25seSBpbiAiQzpcV2luZG93c1xURU1QXCIgKFdpbmRvd3MyMDEy
UjIpLg0KDQpCZXN0IHJlZ2FyZHMsDQpEYW5nIE1pbmggSHVvbmcNCk5FQyBTb2x1dGlvbiBJbm5v
dmF0b3JzLCBMdGQuDQpodHRwOi8vd3d3Lm5lYy1zb2x1dGlvbmlubm92YXRvcnMuY28uanAvZW4v
DQoNCj4gLS0NCj4gDQo+ICBDcmFpZyBSaW5nZXIgICAgICAgICAgICAgICAgICAgaHR0cDovL3d3
dy4ybmRRdWFkcmFudC5jb20vDQo+ICBQb3N0Z3JlU1FMIERldmVsb3BtZW50LCAyNHg3IFN1cHBv
cnQsIFRyYWluaW5nICYgU2VydmljZXMNCg0K

On 20 January 2016 at 16:22, Huong Dangminh <huo-dangminh@ys.jp.nec.com>
wrote:


>
> initdb was executed with "Administrator" privileges, but
> then initdb do popen() with none "Administrator" privileges
> (by child process).
>

That makes sense. It intentionally drops privileges.

You probably have to set the ACLs up so that it can still see and write to
the directory even after it has dropped privileges. That will include
setting ACLs on the parent directories so that it can see inside them.
Explicitly granting rights to the admin user you're running as is probably
sufficient but I'm not sure.

The best thing to do is probably to run initdb with non-administrator
rights and grant permissions directly.

This is the same kind of problem you get on linux systems if you 'cd' to
some root-only directory then 'sudo -u somenormaluser ls'. You get an error
saying the current directory isn't readable or similar.

--
 Craig Ringer                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

On 1/20/2016 12:30 AM, Craig Ringer wrote:
> On 20 January 2016 at 16:22, Huong Dangminh
> <huo-dangminh@ys.jp.nec.com <mailto:huo-dangminh@ys.jp.nec.com>> wrote:
>
>
>     initdb was executed with "Administrator" privileges, but
>     then initdb do popen() with none "Administrator" privileges
>     (by child process).
>
>
> That makes sense. It intentionally drops privileges.
>
> You probably have to set the ACLs up so that it can still see and
> write to the directory even after it has dropped privileges. That will
> include setting ACLs on the parent directories so that it can see
> inside them. Explicitly granting rights to the admin user you're
> running as is probably sufficient but I'm not sure.
>
> The best thing to do is probably to run initdb with non-administrator
> rights and grant permissions directly.
>
> This is the same kind of problem you get on linux systems if you 'cd'
> to some root-only directory then 'sudo -u somenormaluser ls'. You get
> an error saying the current directory isn't readable or similar.


in the newer versions of Windows (Server 2012 is roughly equivalent to
Windows 8), the \Windows\ directory is heavily protected from user
processes doing much of anything.   This is almost akin to what selinux
does to the linux system directories, but much less configurable.

there's no WAY I would want to put a postgres database in there.   I
generally create a \PostgreSQL\ directory in the root of whatever drive
I'm going to put my data in, then a X.Y (9.4 or whatever) directory
under that, and a data directory under that...  so
C:\PostgreSQL\9.4\data would be my default choice of data directories
for 9.4 on a C: only system, if the system has a separate data volume,
of course I'd use that instead.


--
john r pierce, recycling bits in santa cruz

On 2016-01-19 22:45, Dang Minh Huong wrote:
> > owner@postgresql.org] On Behalf Of Thomas Kellerer
> > Huong Dangminh schrieb am 19.01.2016 um 11:49:
> > > I have failed in execute initdb in "c:\Windows\Temp\dir" folder as
> > > reproduce logs below. The OS's messages "The current directory is invalid."
> > > was returned.
> >
> > c:\Windows has special protection and it is not really surprising that a regular
> > user isn't allowed to write into that directory.
> >
> > When Postgres is started it drops all "Administrator" privileges for security
> > reasons (older versions would refuse to start as
> > Administrator) - and I think initdb is doing the same thing.
> > So it's understandable that it can't write to c:\Windows
> >
>
> I did not mean, create data cluster in C drive made that error sir.
> This issue reproduce in all drive specified in -D option.
> # My reproduce environment is only one (C) drive. So, sorry for the log.
>
> I mean, it happen when current directory of command line is "c:\Windows\Temp\something".
> It is rare case, and may be a Windows2012's specification, but i don't know
> why only "c:\Windows\Temp\something" and are there another case like that?
>
> > Putting application data into c:\Windows (or "c:\Program Files" for that
> > matter) is an extremely bad idea to begin with (c:\Windows being even
> > worse than "c:\Program Files")
> >
> > You shouldn't be doing that anyway.

As Thomas said, it is undesireable to log into a server as
administrator. You should create and use a privileged user, for
example dmhadmin, insert that user into the administrators
group. Also create an ordinary user, perhaps dmh, and log in
with that account. Download the postgres installer, run it as
the ordinary user. You will be prompted for a privileged user
account, enter the priviledged account (for example, dmhadmin).
When asked for the location to install the database, create a
new folder named postgres on a non-system (not C:) disk. If your
server can only have one disk you might install the database in
C:\postgres, which you'll have the opportunity to create from
inside the installer's "browse..." dialog. This folder will be
owned by the local server's "administrators" group with
appropriate privileges.

C:\Windows\Temp is not an appropriate choice for storing
persistent program data. If you ignore this by manipulating the
permissions you will eventually be harmed when a privileged
program clears the entire contents.

Hope that helps,
--
Charles

Hi,

Thank you all for your advices.

We have simply solved this problem with change the running initdb's folder t=
o not to "c:\windows\temp\something".

Best regards,
bocap.

Ng=C3=A0y 20-01-2016, v=C3=A0o l=C3=BAc 07:28, cpolish@surewest.net vi=E1=BA=
=BFt:

> On 2016-01-19 22:45, Dang Minh Huong wrote:
>>> owner@postgresql.org] On Behalf Of Thomas Kellerer
>>> Huong Dangminh schrieb am 19.01.2016 um 11:49:
>>>> I have failed in execute initdb in "c:\Windows\Temp\dir" folder as
>>>> reproduce logs below. The OS's messages "The current directory is inval=
id."
>>>> was returned.
>>>=20
>>> c:\Windows has special protection and it is not really surprising that a=
 regular
>>> user isn't allowed to write into that directory.
>>>=20
>>> When Postgres is started it drops all "Administrator" privileges for sec=
urity
>>> reasons (older versions would refuse to start as
>>> Administrator) - and I think initdb is doing the same thing.
>>> So it's understandable that it can't write to c:\Windows
>>=20
>> I did not mean, create data cluster in C drive made that error sir.
>> This issue reproduce in all drive specified in -D option.
>> # My reproduce environment is only one (C) drive. So, sorry for the log.
>>=20
>> I mean, it happen when current directory of command line is "c:\Windows\T=
emp\something".
>> It is rare case, and may be a Windows2012's specification, but i don't kn=
ow
>> why only "c:\Windows\Temp\something" and are there another case like that=
?
>>=20
>>> Putting application data into c:\Windows (or "c:\Program Files" for that=

>>> matter) is an extremely bad idea to begin with (c:\Windows being even
>>> worse than "c:\Program Files")
>>>=20
>>> You shouldn't be doing that anyway.
>=20
> As Thomas said, it is undesireable to log into a server as
> administrator. You should create and use a privileged user, for
> example dmhadmin, insert that user into the administrators
> group. Also create an ordinary user, perhaps dmh, and log in
> with that account. Download the postgres installer, run it as
> the ordinary user. You will be prompted for a privileged user
> account, enter the priviledged account (for example, dmhadmin).
> When asked for the location to install the database, create a
> new folder named postgres on a non-system (not C:) disk. If your
> server can only have one disk you might install the database in
> C:\postgres, which you'll have the opportunity to create from
> inside the installer's "browse..." dialog. This folder will be
> owned by the local server's "administrators" group with
> appropriate privileges.=20
>=20
> C:\Windows\Temp is not an appropriate choice for storing
> persistent program data. If you ignore this by manipulating the
> permissions you will eventually be harmed when a privileged
> program clears the entire contents.
>=20
> Hope that helps,
> --=20
> Charles
>=20