Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
>Fish wrote: >> There are no deny ACL settings, it's just full control for that group, the >> local administrators group, and the local SYSTEM account from the root of > >the > >> repository on down. Auditing is also not enabled, so no additional info >> there. >> >> Any other ideas? Filesystem permissions on the repository itself seem to be >> just fine. > >Try making sure that the users have at least Read and List permissions >on all directories above the repository as well, up to the root >directory of the drive. I had a problem with Apache when it was only >given the specific permissions on the (deeply nested) directory where >it's htdocs were, this could be similar. That was it. The directory above the cvs repository had no permissions for the group in question... Thing is, it used to work fine in the older version we were running. Now, I have a new problem. Everything works fine for my domain users now, but I need to add access for some remote contractors. So I set up a domain-level account, put it in the normal domain-level group that I gave access to, and try to alias the contractors to the real account. I login, and then I try to cvs -d <repo stuff> -a -r <domain>\<realaccount> testuser. I'm prompted for a password, and I give it one. Now when I try to auth as that user with pserver authentication, if I enter the correct password it tells me <domain>\<realaccount> no such user. If I give it the wrong password, it tells me authorization failed, server rejected access. So it's definitely not a problem with being able to authenticate the garbage user, it just can't find the other account. If I try to authenticate as the real user with SSPI it works fine. If I alias the user to my account, which is an admin on the machine, it works fine. This can't be a permissions problem on the filesystem... What am I missing here? The service is running as the local system account. Thanks, Fish