Thread: initdb error: "could not identify current directory" (or, what have i done now?)

hi all,

i just clean-rebuilt pgsql8b5 os OSX 10.3.6

the build went fine as before -- no errors reported.

per instruction, i've created an unpriv'd user: testuser.

now, however, when i try to 'initdb', creating in '/var/data/pgsql':

> su testuser
% /usr/local/pgsql/bin/initdb --pgdata=/var/data/pgsql --username=testuser
--debug

i get the following shell output:

    could not identify current directory: Permission denied
    Running in debug mode.
    could not identify current directory: Permission denied
    could not identify current directory: Permission denied
    The program "postgres" is needed by initdb but was not found in the
    same directory as "initdb".
    Check your installation.


checking my pgsql/bin DIR,

   % ls -al /usr/local/pgsql/bin

        clusterdb   droplang  pg_config       pg_resetxlog   postgres
        createdb    dropuser  pg_controldata  pg_restore     postmaster
        createlang  ecpg      pg_ctl          pltcl_delmod   psql
        createuser  initdb    pg_dump         pltcl_listmod  vacuumdb
        dropdb      ipcclean  pg_dumpall      pltcl_loadmod

'initdb' and 'postgres' _are_ in the same location.

poking around in the src,

   % grep -rln "could not identify current directory" .
        ./src/port/exec.c

i find:

    if (!getcwd(cwd, MAXPGPATH))
    {
        log_error(_("could not identify current directory: %s"),
                  strerror(errno));
        return -1;
    }

which seems to be abt finding absolute paths to executables ...  why it
'stopped' working between last nite and this morning, i have no idea.

i also note a comment:

   "Finally, we want a true path not a symlink location"

fwiw, the dirs involved are both symlinked

    /usr/local/pgsql/bin/initdb <-- ln -s /Volumes/devhd/local/pgsql
    /var/data/pgsql <-- ln -s /Volumes/data/pgsql

but that hasn't changed for ages!

there's an old thread abt this:

   <http://archives.postgresql.org/pgsql-hackers-win32/2004-05/msg00252.php>

but not clear how it applies to the current 8b5, if at all.

suggestions?


arrgh,

richard

p.s. i swear on a stack of oreos, i had this working last night ...

OpenMacNews <pgsql-general.20.openmacnews@spamgourmet.com> writes:
>> su testuser
> % /usr/local/pgsql/bin/initdb --pgdata=/var/data/pgsql --username=testuser
>     could not identify current directory: Permission denied

What directory are you in when you give this command?  (AFAIR su doesn't
change directory ... you might be better off with su - testuser ...)

            regards, tom lane

hi there,

>> % /usr/local/pgsql/bin/initdb --pgdata=/var/data/pgsql --username=testuser
>>     could not identify current directory: Permission denied
>
> What directory are you in when you give this command?  (AFAIR su doesn't
> change directory ... you might be better off with su - testuser ...)

hmmmm, that's an interesting question.

per your suggestion i tried "su - testuser", then various combos of su, su -,
sudo, etc, etc. -- all to no avail.

then, i stumbled across the following behavior.:

(1)

% rm -rf /var/data/pgsql /Volumes/data/pgsql

% ls -ald /var/data/pgsql
    lrwxr-xr-x  1 root wheel 27 Nov 22 20:26 /var/data/pgsql -> /Volumes/data/pgsql

% ls -ald /Volumes/data/pgsql
    drwxrwxr-x  12 testuser testuser 408 Nov 25 09:12 /Volumes/data/pgsql

% cd /var/data/pgsql
% pwd
    /Volumes/data/pgsql

% sudo -u testuser /usr/local/pgsql/bin/initdb --pgdata=/var/data/pgsql
--username=testuser

IT CHOKES.

with:

    could not identify current directory: Permission denied
    could not identify current directory: Permission denied
    could not identify current directory: Permission denied
    The program "postgres" is needed by initdb but was not found in the
    same directory as "initdb".
    Check your installation.

(2)

% rm -rf /var/data/pgsql /Volumes/data/pgsql

% ls -ald /var
    lrwxr-xr-x  1 root admin 11 Nov 23 10:28 /var -> private/var

% ls -ald /private/var
    drwxr-xr-x  24 root wheel 816 Dec  3 14:51 /private/var

% cd /var
% pwd
    /private/var

% sudo -u testuser /usr/local/pgsql/bin/initdb --pgdata=/var/data/pgsql
--username=testuser

IT WORKS.

% ls -ald /var/data/pgsql
    drwx------  12 testuser testuser 408 Dec  3 16:03 /var/data/pgsql
% ls /var/data/pgsql
    PG_VERSION  global   pg_hba.conf    pg_subtrans  pg_xlog
    base        pg_clog  pg_ident.conf  pg_tblspc    postgresql.conf


now, i'd guess that that indicates a problem with
(a) exec.c's getcwd,
(b) my understanding of the behavior of 'su' et al ..., and/or
(c) perms/ownership

*something* doesn't like being *in* a dir owned by testuser:testuser ...

fwiw, note also:

    % niutil -read / /users/testuser
        name: testuser
        shell: /bin/tcsh
        realname: Test User
        uid: 57
        gid: 57
        change: 0
        expire: 0
        _shadow_passwd:
        generateduid: 9ED08FE5-3755-11D9-8050-0025038BA5BD
        authentication_authority: ;ShadowHash;
        passwd: ********

    % niutil -read / /groups/testuser
        name: testuser
        gid: 57
        users: testuser root admin daemon

what've i missed?

cheers,

richard

OpenMacNews <pgsql-general.20.openmacnews@spamgourmet.com> writes:
> then, i stumbled across the following behavior.:

> % rm -rf /var/data/pgsql /Volumes/data/pgsql

> % ls -ald /var/data/pgsql
>     lrwxr-xr-x  1 root wheel 27 Nov 22 20:26 /var/data/pgsql -> /Volumes/data/pgsql

> % ls -ald /Volumes/data/pgsql
>     drwxrwxr-x  12 testuser testuser 408 Nov 25 09:12 /Volumes/data/pgsql

Huh?  Why didn't the rm -rf remove both of those?  Or are you skipping
some steps?

> % cd /var/data/pgsql
> % pwd
>     /Volumes/data/pgsql

This is odd ... when I do pwd I see the path as it was told to cd.  I
have to say /bin/pwd to get what you're showing.

> % sudo -u testuser /usr/local/pgsql/bin/initdb --pgdata=/var/data/pgsql
> --username=testuser

> IT CHOKES.

Couldn't reproduce this, using fully up-to-date 10.3.6.

The man page for getcwd does say that it will fail with EACCES (ie,
"permission denied") if any component of the path is unreadable.
You didn't show us all the steps of the paths /private/var/data and
/Volumes/data ... maybe there's a non-world-readable directory involved?

            regards, tom lane

hi tom,

>> % ls -ald /Volumes/data/pgsql
>>     drwxrwxr-x  12 testuser testuser 408 Nov 25 09:12 /Volumes/data/pgsql
>
> Huh?  Why didn't the rm -rf remove both of those?  Or are you skipping
> some steps?

oops, sorry, copy-n-paste-itis:

   % rm -rf /var/data/pgsql/* /Volumes/data/pgsql/*

>> % cd /var/data/pgsql
>> % pwd
>>     /Volumes/data/pgsql
>
> This is odd ... when I do pwd I see the path as it was told to cd.  I
> have to say /bin/pwd to get what you're showing.

my pwd is aliased to:

    alias pwd   '/bin/pwd ;\\
                set prompt = "[$myUser@%m]`dirs`> " ;\\
                if (`dirs` == "~") set prompt = "[$myUser@%m]~ > "'

checking in my ~/.cshrc, tho', it had -- apparently -- been munged in a
copy-n-paste to:

    alias pwd   '/bin/pwd ;\\
                set prompt = "[$myUser@%m]_Dirs`> " ;\\
                if (`dirs` == "~") set prompt = "[$myUser@%m]~ > "'

so,

(a) i corrected the alias

% sudo -u testuser /usr/local/pgsql/bin/initdb --pgdata=/var/data/pgsql
--username=testuser
--> still WORKS  if cd to /var first
--> still CHOKES if cd to cd /var/data/pgsql first

% cd /var/data/pgsql
still reports the absolute path
--> /Volumes/data/pgsql

(b) i unaliased pwd

checking

% alias pwd
% which pwd
    /bin/pwd

same results



hmmmm .... why are you getting different results for 'pwd' and '/bin/pwd'

what does YOUR 'which pwd' tell you?

> Couldn't reproduce this, using fully up-to-date 10.3.6.

my gut sez this has GOT to do with my symlinks, etc. ...

> The man page for getcwd does say that it will fail with EACCES (ie,
> "permission denied") if any component of the path is unreadable.
> You didn't show us all the steps of the paths /private/var/data and
> /Volumes/data ... maybe there's a non-world-readable directory involved?

methinks you're on to something ...

after cd-int to /var, and inidb'ing ... tho' it DOES create the dirs/data, i
caught:

    getcwd: cannot access parent directories: Permission denied


so, per reuqest, here are the steps to the path:

    % unalias pwd
    % which pwd
        /bin/pwd


    % ls -ald /private/var
        drwxr-xr-x  24 root     wheel    816  /private/var
    % ls -ald /var
        lrwxr-xr-x   1 root     admin     11  /var -> private/var
    % ls -ald /var/data
        lrwxr-xr-x   1 root     wheel     27  /var/data -> /Volumes/data
    % ls -ald /var/data/pgsql
        drwx------  12 testuser testuser 408  /var/data/pgsql

(i)
    % cd /private/var
    % pwd
        /private/var

(ii)
    % cd /var
    % pwd
        /private/var

(iii)
    % cd /var/data
    % pwd
        /Volumes/data


(iv)
    % cd /var/data/pgsql
    % pwd
        /Volumes/data/pgsql


those 'pwd' results have me a bit confused ... sumthin's not right.

(iii) & (iv) are 'pwd's IN a symlinked dir, and result in the full path.

(i) is a 'pwd' in an absolute dir, and returns the absolute path

BUT, (i) is a pwd IN a symlinked path, yet returns the absolute path, unlike
(iii)/(iv)


i need to stare some more, and dig a little on getcwd.

again, i think pwd's, and perhaps getcwd's, behavior in _my_ symlinked
dirs/path + perms scenario may be the culprit ...

thoughts?

richard

hi tom,

per this thread, i've been googl'ing on 'getcwd initdb permissions parent' and
find lots of refs ... issues with folks having 'permission denied' errors if
parent directories don't have correct permissions, etc.

this 'smells' pretty much like the issue at hand here ... tho' i dunno (yet)
what permissions i don't have set correctly.  i think the symlinked directories
have confused matters -- well, at least they've confused me.  i'm going
slightly cross-eyed tonite; will check further in the morning ...

if you have any further insight as to where the issue is, ple let me know ...
otherwise, i think it may be time to drop back to all local/absolute dirs and
start iterating through changes ...

cheers again & thx! for all your help!

richard

hi tom,

i think i got it ...

keeping in mind your question re: read perms, & reading this thread:


<http://groups.google.com/groups?hl=en&lr=&threadm=60b4un%24cqh%241%40dolphin.neosoft.com&rnum=2&prev=/groups%3Fq%3Dgetcwd%2520permissions%2520symlink%26hl%3Den%26lr%3D%26sa%3DN%26tab%3Dwg>

and noting there "suspicion would be that one of your mointpoints (like /usr)
has mangled permissions", it seems it's the mount point in the path of the
relevant symlink that needs the right perms.

for me that's, e.g.,  /Volumes/data

tho' i'd reported:

    % ls -ald /var/data
        lrwxr-xr-x   1 root     wheel     27  /var/data -> /Volumes/data

its actually (apparently) the perms on the absolute dir path /Volumes/data that
matter ... to getcwd.

on my sys:

   % ls -ald /Volumes/data
        drwxr-x--x  12 openmac wheel 408 Nov 27 15:25 /Volumes/data/

the thread (above) mentioned changing perms to at least 555 on the mount point,
so i:

   % chmod 755 /Volumes/data
   % ls -ald /Volumes/data
        drwxrwxr-x  12 openmac wheel 408 Nov 27 15:25 /Volumes/data/

and tried initdb again.

so far (!) it seems to run fine without the getced 'persmission denied' errors
from any directory.

i'll test this some more in the morn, and make sure i'm not deluding myself ...

if this *does* turn out to be the case, does it make sense to have the script
check perms up through the physical/path of the cwd and report with a more
specific/desciptive error if they're not at least 555 on the mount point?

thx & g'nite.

richard

OpenMacNews <pgsql-general.20.openmacnews@spamgourmet.com> writes:
> on my sys:

>    % ls -ald /Volumes/data
>         drwxr-x--x  12 openmac wheel 408 Nov 27 15:25 /Volumes/data/

Ah-hah, yes that's undoubtedly it.

> if this *does* turn out to be the case, does it make sense to have the script
> check perms up through the physical/path of the cwd and report with a more
> specific/desciptive error if they're not at least 555 on the mount
> point?

I'm not in the business of reimplementing getcwd(); especially not to
deal with a problem that will break many other things besides Postgres.
I'd suggest filing a bug against whatever tool you used to create
/Volumes/data/, suggesting that they adopt a less brain-dead default
permissions setting.  Execute-only on a mount point is just silly.

            regards, tom lane

hi tom,

>>    % ls -ald /Volumes/data
>>         drwxr-x--x  12 openmac wheel 408 Nov 27 15:25 /Volumes/data/
>
> Ah-hah, yes that's undoubtedly it.

and, since i've cleared that up pgsql is, again, behaving. yay.

for posterity's -- and other OSX users' -- sake, that's:

for the relevant drives/mounts in /Volumes, you need:

   perms >= 555 (i use)
   group should include your pgsql unprivileged user
        'default' ownership, i believe, is root:admin for mounts, hence your
pgsql user
        would need to be added as a user to grup:admin

>> if this *does* turn out to be the case, does it make sense to have the script
>> check perms up through the physical/path of the cwd and report with a more
>> specific/desciptive error if they're not at least 555 on the mount
>> point?
>
> I'm not in the business of reimplementing getcwd(); especially not to
> deal with a problem that will break many other things besides Postgres.

whoa! i wasn't suggesting that at all ... rather, perhaps, simply a perms check
from within the initdb script and an 'informative' error to the end-user. if i
were the 1st/only to see such an issue, i'd, of course, not even bother with
the suggestion ... but, as we've seen, it's raised its ugly head elsewhere
(google: 'getcwd initdb')

> I'd suggest filing a bug against whatever tool you used to create
> /Volumes/data/, suggesting that they adopt a less brain-dead default
> permissions setting.  Execute-only on a mount point is just silly.

i have a suspicion it has to do with my filesharing/automount
system/setup/settings.  i'd had a bunch o' headaches a fairly long while back
w/ getting Samba, AFS & NFS to play nice together.  i'm fairly sure perms were
changed, and the mount points may have been (inadvertently?) munged.  why is
'suddenly' changed in the last days, i have no flippin' idea as yet!

postgresql may have been, simply, the 1st (me <-- surprised) app to 'hit' the
getcwd path sensitivity.

hence, i think i have to file a bug-report with myself ...  =)

two points o' feedback:

(a) without your help/suggestions, finiding this would've taken me a *lot*
longer (thx!), and
(b) if this is in the pgsql docs (should it be?), i simply missed, misread or
misunderstood it.

cheers,

richard

OpenMacNews <pgsql-general.20.openmacnews@spamgourmet.com> writes:
> whoa! i wasn't suggesting that at all ... rather, perhaps, simply a perms check
> from within the initdb script and an 'informative' error to the
> end-user.

We're doing the best we can already: when the failure occurs, we really
don't know which directory is the problem, and cannot find out because
we can't navigate above it to find out its name.

I note that pwd is not any better:

g42:~ tgl$ mkdir ~/zit
g42:~/zit tgl$ mkdir ~/zit/zap
g42:~/zit tgl$ chmod 111 ~/zit
g42:~/zit tgl$ cd ~/zit/zap
g42:~/zit/zap tgl$ pwd
/Users/tgl/zit/zap
g42:~/zit/zap tgl$ /bin/pwd
pwd: : Permission denied
g42:~/zit/zap tgl$

(bash is probably not doing anyone any favors by masking the problem in
its built-in PWD command.)

There are limited situations where it makes sense to create a directory
that has execute but not read permissions ("drop box" directories being
the main thing I can think of offhand).  But it's simply wrong to
create a directory that way without a very specific purpose in mind.
You need to try to reconstruct how /Volumes/data/ got to be that way,
and see if it was simple pilot error or if some tool messed up the
permissions for you.

            regards, tom lane

tom,

> We're doing the best we can already: when the failure occurs, we really
> don't know which directory is the problem, and cannot find out because
> we can't navigate above it to find out its name.

good point.  catch-22.

at the very least, some knowledgeable commentary in
docs/FAQ/howto/Troubleshooting/etc could well be useful ...

> I note that pwd is not any better:
>
> g42:~ tgl$ mkdir ~/zit
> g42:~/zit tgl$ mkdir ~/zit/zap
> g42:~/zit tgl$ chmod 111 ~/zit
> g42:~/zit tgl$ cd ~/zit/zap
> g42:~/zit/zap tgl$ pwd
> /Users/tgl/zit/zap
> g42:~/zit/zap tgl$ /bin/pwd
> pwd: : Permission denied
> g42:~/zit/zap tgl$

interesting.  i need to read-up/monkey-around a bit b4 it bites me in the a__
again.

> (bash is probably not doing anyone any favors by masking the problem in
> its built-in PWD command.)

being primarily a tcsh user (yes, i'm old), i did'na kno that.  so *that's* the
diff bet pwd and /bin/pwd on _your_ sys, yes?

> You need to try to reconstruct how /Volumes/data/ got to be that way,
> and see if it was simple pilot error or if some tool messed up the
> permissions for you.

of course, you're right.  i'm betting on occam's razor --> 'pilot error'
(hence, the "(or, what have i done now?)" in the Sub:), but due diligence _is_
called for. (there's a cute/useful mount manager util called SharePoints which
i tried a while back that i _think_ may have made it EASY for me to screw
things up ... not their fault, tho)

again, tom, thanks! now on to make postfix behave w/ pgsql8rc1! =)

best,

richard

> % cd /var/data/pgsql
> still reports the absolute path
> --> /Volumes/data/pgsql

It looks to me like you are attempting to mount a few volumes under /var?

I think that's going to wrinkle your handkerchief in Darwin.

--
Joel Rees   <rees@ddcom.co.jp>
digitcom, inc.   株式会社デジコム
Kobe, Japan   +81-78-672-8800
** <http://www.ddcom.co.jp> **

hi joel,

> It looks to me like you are attempting to mount a few volumes under /var?

actually, no.

i'm symlinking local volumes mounted where they're supposed to be, in /Volumes,
to ny /var/sub-hierarchy.

> I think that's going to wrinkle your handkerchief in Darwin.

it's all been settled, actually (thread's discontinious ... sorry).  turns out
it was the perms/ownership of the actual mount dir /Volumes/XXXXX that were
the(my) problem.

cheers,

richard