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.
> From: cvsnt-bounces at cvsnt.org > [mailto:cvsnt-bounces at cvsnt.org] On Behalf Of Bo Berglund > Sent: Wednesday, 08 February, 2006 17:49 > > On Wed, 8 Feb 2006 13:41:59 -0800, "Michael Wojcik" > <Michael.Wojcik at microfocus.com> wrote: > > >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 Ah, sorry about that. "Effective Permissions" must have been added for XP and 2003. I only use 2000 on some test machines, so I don't remember the differences between it and the later releases. > >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! Well, this is a mystery. > 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! Glad to hear it. > So the problem was *above* the cvstemp dir, at the disk root! Yes, while ACLs are a powerful discretionary access control mechanism, they're just too complicated sometimes. I ran into some terrible problems with ACLs when I was retrieving data from a partially-damaged disk a while back, for example. I only thought of inheritance as a possible problem because I've been working on an ACL system myself recently. > Thanks for tipping me off on the runas command to check what the user > can and cannot do. This was a good troubleshooter thing! Yes, it's quite handy. I'm glad I could help. -- Michael Wojcik Principal Software Systems Developer, Micro Focus