<Data>Database open error on db.server! open: db.server: Access is denied.</Data>
Eventually, what I found out is this:
- SDP uses instsrv to create the service.
- We want to run the service not with the local system account, but with a dedicated domain account with limited permissions.
- Note that instsrv actually helpfully suggests this!
- Registry entries associated with the process (e.g. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\p4_1\Parameters) have permissions like files.
- These keys belonged to the local system account, and the account running the service didn’t have permissions to read these.
- These keys include the `p4 set -S <service> …` setting for P4ROOT and P4LOG. Without permission to read these values, the service was unable to create either the db files or the log files.
Their suggestions on the matter:
1. In the SDP Guide, explicitly address the issue of running the service as a different user, and mention that permissions need to be fixed using regedit.
2. Even better, add an option for this in the SDP configuration and use it as `-a` parameter to instsrv. (I haven’t tried this, but it looks as if this is feature in instsrv.)
3. When failing to read the service’s parameters, produce an error message about this and fail immediately, instead of assuming an arbitrary P4ROOT and P4LOG and then failing because these are not writable.
Not sure if this is possible: Are these variables set in the environment before Windows starts p4s.exe? Then this would still be helpful:
4. If the P4ROOT or P4LOG directories are not writable, show absolute paths in the error message instead of just filenames. That would help a lot in understanding what’s wrong.