Unable to open ... srcsafe.ini

pwhittemore · Post by **pwhittemore** » Thu Mar 02, 2006 7:54 pm

We have a SourceSafe 3.5.3 server running on a dedicated server machine. We have connected to multiple databases on a separate file server for several years, but recently created a new database on a different file server. After adding this database and restarting the SoS service, it does not appear in the list of available databases. The log.txt file reports:

Unable to open \\192.168.120.36\fc01source\dev06\srcsafe.ini

SourceSafe Initialization file(s) located at:
\\192.168.120.3\Source\SS0410\srcsafe.ini
\\192.168.120.3\Source\SS82\srcsafe.ini

Here, you can see it successfully opened the older two databases on the .3 machine, but not the new one on the .36 machine.

I have always provided access to these databases by actually logging in and mapping the required volume as a drive on the local machine, then starting the SoS server. This works fine in two cases above, but not the third.

I don't think this is an access problem from the actual INI file, as I can copy and paste the path from this error report to notepad and open the INI file and save changes. I appear to have full read-write access when testing from the Windows login session. Yes, I realize this is different than the LocalSystem account the service runs under, but I have never had any trouble mounting the volume after login and having the service recognize the mounted volume, either by name or via drive letter. (Both work for the first server, neither work for the second server.)

Also, I'd like to suggest that reporting the error code here would probably make the problem a lot easier to diagnose. However, I was very grateful to even find the error report in the log.txt file.

This allows me to test new attempts to fix the problem by restarting the service and checking the log file -- no client required.

I saw your other message about specifying login credentials in the service setup. I don't see how that could be used in this case as I need to log in to two different file servers with differnet credentials. And since I can successfully access files on the old file server, if I log in manually on the machine, it should work for the new server two.

One final data point: If I start SourceSafe itself, it has no trouble accessing the SS database.

Are there any limitations in server path length, etc? I noticed the new path was longer.

Any hints or suggestions you may have would be greatly appreciated.

Thanks.

lbauer · Post by **lbauer** » Fri Mar 03, 2006 11:21 am

Unable to open \\192.168.120.36\fc01source\dev06\srcsafe.ini

This error in the log means the SOS Server Service cannot access the VSS database location.

We generally recommend browsing to the database location, rather than using a mapped drive.

The account used by the SOS Server service must have access to each VSS database location -- ideally, you would use a domain account has access to both locations.

pwhittemore · Post by **pwhittemore** » Fri Mar 03, 2006 11:38 am

lbauer wrote:
Unable to open \\192.168.120.36\fc01source\dev06\srcsafe.ini
This error in the log means the SOS Server Service cannot access the VSS database location.

Thanks for your quick reply. I did understand that part...

We generally recommend browsing to the database location, rather than using a mapped drive.

I'm not sure what difference you mean by that -- I did use the Browse button to enter the path. And as you can see from the error message, it was not a mapped drive letter, but rather the full UNC path with an IP address... Regardless, browsing is just a mechanism for entering the path. I could have pasted the same UNC path as well and it would have the exact same effect as using the Services "Browse" button to browse to that location. Still, even a browsed location produces the same error.

The account used by the SOS Server service must have access to each VSS database location -- ideally, you would use a domain account has access to both locations.

I hope that you aren't saying SoS requires us to set up a domain controller! (We don't use one and our IT folks would probably freak if I suggested it... )

And I hope you're not suggesting that manually providing the connections for the service works for only one server connection, as I know that the alternative of having the service log in directly only works for a single file server (authentication context) without a domain controller...

The bottom line is that it has access to the files on both servers, and yet produces this error for one of them. Are there no known problems with using two file servers? Has anybody else tried this or am I really the first one. We are trying to migrate to a new machine, without disrupting access to the old file server...

lbauer · Post by **lbauer** » Fri Mar 03, 2006 5:09 pm

What account is the SOS Server service using?

pwhittemore · Post by **pwhittemore** » Fri Mar 03, 2006 5:18 pm

lbauer wrote:What account is the SOS Server service using?

The LocalSystem account.

Yes, I know it has no access to network volumes by default. That's why I manually add them after startup, using my file server logon credentials, then I restart the SoS service.

As far as I know, there is no way to specify file server login credentials for more than one file server within the service config forms.

This is working for the old file server, and the new one clearly also has access after I connect to them, but yet SoS can see one but not the other.

pwhittemore · Post by **pwhittemore** » Mon Mar 06, 2006 2:09 am

lbauer wrote:
Unable to open \\192.168.120.36\fc01source\dev06\srcsafe.ini
This error in the log means the SOS Server Service cannot access the VSS database location.

We generally recommend browsing to the database location, rather than using a mapped drive.

Okay, an update. We had a drive failure on the old file server (fortunately RAID5) so we took the opportunity to move all the old SourceSafe databases to the new file server. This puts them all on a single server.

However, now I get this "unable" error for all three databases. Even if I browse to the location of the INI file.

It is not very informative. No error codes or anything like that.

The account used by the SOS Server service must have access to each VSS database location -- ideally, you would use a domain account has access to both locations.

I thought I was "home free" on this problem now, since they were all on one server with one account accessing them, but the Services control panel will not let me specify the user ID of the account on the file server; it must be a local account.

If I create a local account with the same name, e.g. "paul", then the login credentials for the service will be those of the local machine, not the file server. Does SourceOffSite have any support for mapping drives at startup? If not, I don't understand how your initial instruction as to how to access a SourceSafe database on a file server could work? How do you tell it what userid/password to log in with? What volumes to mount?

I have the service set to log in as me now, and when I try to start it, it fails to start. Checking the log:

Unable to open \\192.168.120.36\source\SS82\srcsafe.ini
Unable to open S:\SS0410\srcsafe.ini
Unable to open \\192.168.120.36\fc01source\dev06\srcsafe.ini
Invalid databases

The "Invalid databases" message is new, but perhaps because there are no successes anymore. As you can see, I did a "browse" and picked one of them that way (the SoS manager replaced the browsed path with a drive letter, so that ends up testing things both ways -- neither works).

I cannot get it to open any of these INI files, even though I can open it (and save changes) from Notepad, and even though SourceSafe works on the same machine. I've tried setting it up as an interactive LocalSystem login, and to log in as me, and in both cases, I get the same generic failure message. The message is not very informative. No error codes or anything like that to work with.

Paul

pwhittemore · Post by **pwhittemore** » Tue Mar 07, 2006 2:52 am

I have resolved this problem. There is a crucial piece of info that I was missing before, so I will share that now in case anyone runs into this in the future and searches this forum.

If you do not use the LocalSystem account, but instead specify a login user and password, the password on the remote file server must match the password for the local account that the service is logging in to, or the service will not be able to log in to the network file server.

I know this is going to sound obvious in hindsight, but I was using a newly-created file server account where the password was still set to a temporary password. Since Windows prompted me for login credentials and asked if it should reconnect at login, I assumed it was saving that password somewhere in the data for that local user (like a keychain), but this was not true.

I could not understand how this was working for me as a user, but not as the logged in service, and it was simply that Windows 2000 (hosting the SoS service) does not save passwords for file server logins. At all. However, it will try the password for the current account on the local machine. So as long as you make them match, it will work. But if they don't match, even if you type in the password and check the reconnect box, it will not be able to reconnect.

There are all kinds of other "gotchas" that I was aware of, like you can't map a drive in one user session that is in use in another user (or service) session, on Win2K -- drive letters are global to the machine on Win2K. (You can do this on XP and 2003 as each session has it's own logical drives.) And you can't connect to two different shares on a given file server with two different sets of credentials. I was ready for those, but I did not understand where the passwords were saved; the answer is that they are not saved at all.

Hope this helps someone.

P.S. It would still be extemely helpful if the developers of SourceOffSite would find it in there hearts to report an actual error code once in a while.

lbauer · Post by **lbauer** » Tue Mar 07, 2006 9:33 am

Thanks for the update.

If you do not use the LocalSystem account, but instead specify a login user and password, the password on the remote file server must match the password for the local account that the service is logging in to, or the service will not be able to log in to the network file server.

Yes, this can work in cases when there is no domain account to use -- a matching username/password on the SOS Server machine and the VSS database machine. Some users have also been able to use this configuration when trying to connect to VSS databases on Novell systems or Samba drives.