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.
On Wed, 8 Feb 2006 13:41:59 -0800, "Michael Wojcik" <Michael.Wojcik at microfocus.com> wrote: >Well, it looks like you've confirmed that the CVS server is operating >under the domain\cvs_setup account, anyway. That's useful. > >When you checked the permissions for D:\CVSTEMP, did you use the >Effective Permissions tab (Security -> Advanced -> Effective Permissions >-> Select and enter "domain\cvs_setup") to verify that you were looking >at the results for that user account, including all inherited >permissions? I don't have such a tab at all. On mine there are only 3 tabs in the Advanced page: Permissions, Auditing and Owner The operating system is Windows 2000 Server > >If that looks OK, then I'd try the following: > >- Use runas to start a command prompt as the domain\cvs_setup user. >(You may have to temporarily enable login for that user, etc.) > >- cd to d:\cvstemp and create a directory with md. This is *it*! After again removing cvs_setup from the Admin group I created a "runas" command window and tried to do d: and was rewarded by a "Access denied" message! So it appears that the cvs_setup user is not even allowed to do anything at all on the D: disk! If I rightclick the D: disk in Windows Explorer and look at the security tab I see a list that includes *only* the Administrators group and nothing else at all! No wonder that cvs_setup cannot access the D: drive. But how can anyone of my developers work on this drive (which is the data drive for the CVS repositories)? Seems strange to me. Everyone but me should be blocked! So now I added the domain\CVS_users group to the list and then I checked that the permissions were only list/traverse/read. Then I tried the runas window again for creation of dirs on D: and it worked fine so I finally tested the cvs command from another PC using the pserver login that failed before. Hooray! Now this worked as expected! So the problem was *above* the cvstemp dir, at the disk root! Thanks for tipping me off on the runas command to check what the user can and cannot do. This was a good troubleshooter thing! /Bo (Bo Berglund, developer in Sweden)