Labeling VSS - Cannot Access Rights.dat

I am trying to have TeamCity label a project in VSS.  I know it is not supported through the Automated means, but there is a command line option provided by the ss.exe to label a given project.  I have gotten this mostly setup, but the VSS User that TeamCity uses doesn't not have Add/Rename/Delete permissions (aka Write access) and therefore could not create labels.

After trying to give the VSS User that TeamCity uses write access in VSS, I am now getting the following error on all of my projects:

"Access to file "..\data\rights.dat" denied. Source:SourceSafe
Unable to log into SourceSafe.

I found the following thread from two years ago:, but it doesn't really have any solutions for how he fixed the issue.

To preempt the advice given there:
[quote]Please check the following:
- TeamCity server is not running under LOCAL_SYSTEM account
- TeamCity server service is running under some domain account
- That account have enough permittions to access SourceSafe network share
- It does not recommended to use mapped network drives to define a path[/quote]

1. TeamCity server is not running under LOCAL_SYSTEM account
2. While TeamCity server is not running on a Domain account, it is running on an account that has previously been working.
3. Again, this was working in the past with the only change being that the VSS User went from ReadOnly to Add/Rename/Delete.  Additionally, we gave Full Control to the Windows user just to be safe.
4. We are using a mapped network drive, but again it was working in the past...

Furthermore, making the VSS User ReadOnly again clears up the error, but then I can't create labels...

Any help you can give would be appreciated.


1 comment
Comment actions Permalink

I was able to fix this issue, which was an issue with permissions on my end.

We originally were going to use a domain account to run TeamCity and this domain account was the account that had permissions on our VSS database for everything.  Because the computer we are running TeamCity on is not actually on the domain, we couldn't use the domain user.  Instead, we created a local user with the same name.  This lead to confusion (on our part, not the comptuer's) of who had what permissions.  All the users had Read access to the VSS files, which was enough to monitor VSS but not to do whatever it does with the rights.dat file.

This does still beg the question though: Why does the TeamCity user need more than Read access to the rights.dat file?  It doesn't appear to actually be making any changes (as the modified date does not change), but it won't work unless the TeamCity user has more than Read access to the file.



Please sign in to leave a comment.