v.3.5.3 service account doesn't work unless in admin gp

bab5139 · Post by **bab5139** » Mon Nov 06, 2006 8:47 am

We decided to use a domain account for the sourceoffsite service and it no longer works unless the account is in the administrators group of the computer. Please tell me how i can fix this as this account should not have administrator rights?

Beth · Post by **Beth** » Mon Nov 06, 2006 9:44 am

Does the account running the SOS Server service has at least read/write access to the machine/drive/directory where the VSS database resides?

When running my own test on this, I found I had to explicitly give the user that SOS was running under access to the VSS databases.

bab5139 · Post by **bab5139** » Mon Nov 06, 2006 2:52 pm

Beth wrote:Does the account running the SOS Server service has at least read/write access to the machine/drive/directory where the VSS database resides?

When running my own test on this, I found I had to explicitly give the user that SOS was running under access to the VSS databases.

Yes I have made sure of that. It is only when the domain user is in the administrators group of the Sourceoffsite server that it works. If the domain user is in the users group it doesn't. The sourcesafe database is on another server in which it has been given rights to read and write.

Beth · Post by **Beth** » Mon Nov 06, 2006 5:34 pm

Would being a member of the Power Users group be acceptable?

bab5139 · Post by **bab5139** » Wed Nov 08, 2006 7:34 am

I assume so. I really didn't want that account to have any (administrative) permissions on the computer at all. I figured there was a way to do it by giving the account over the com component but everything that microsoft suggested failed.

Beth · Post by **Beth** » Tue Dec 12, 2006 4:26 pm

I checked up on this and what I found is that the SOS directory also needs permissions set for the user SOS is running under as well as the VSS database location. You will also want to make sure that permissions are inherited from the folder at the top of those directories. In that way, SOS can run under a regular domain user account. If it still doesn't work, try giving that user full control of the two directories mentioned.

Another option is to run SOS as an application rather than as a service as mentioned here: http://support.sourcegear.com/viewtopic.php?t=5704.