>When trying to run postgres in Windows with a non-admin
>account, we are
>running into issues with network drives.
>
>Currently we run the DB server as a separate user because that's
>what postgres wants (it doesn't like to be admin).
>
>But on Windows, the mapped drives letters (to network drives) are
>unique to a user session. So when starting postgres as a different
>user, it can't see the network drives. Since our application
>requires the data to
>be residing in the network drive and not the local drive, we
>have the issue.
>
>One option is to map the drives after startup of user process
>(more code required to record and do this). But this user process
>will most likely not have the required permissions to access the
>file anyways. Since the user is a local user and not a domain user
>they have not network wide id, so it can only access network resources
>as world. It could potentially map drives as a different user (the
>original), but then it needs that userid/password (which it doesn't
>have).
>
>Does anyone have a suggestion on how to resolve this issue.
>This looks like a common
>problem and any suggestion will be appreciated.

Use UNC paths, that is \\SERVER\SHARE\DIR\FILE. This will require a
domain user - there is no way around that, other than setting up an
anonymous share (and you shouldn't do that :P).

Your other option is to log in manuallty as the postgres account (with
the service *stopped*, this si important). Map the drives with
persistance. Then log off, *then' start the service. That should work,
but I would personally never rely on that for a production system.

That said, I'm also not sure I'd trust postgresql running over a Windows
share. In theory it should work fine, but I'm not certain enough on how
things like fsync() are handled over those. Perhaps someone else can say
something about that.

//Magnus

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings