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.
After much experimentation, I eventually found a solution. On the NTFS directory where the repository resides, instead of assigning "Full Control" to a group I am a member of, I assigned "Full Control" to my user account directly. This way it works. Don't ask me why, maybe there is some weird interaction between impersonation and access control that requires that a subject being impersonated needs to be assigned to access control lists directly instead of through security groups, who knows? "Bo Berglund" <bo.berglund at telia.com> wrote in message news:<hjquou046m88k5lrfhes490jjdfk69pd60 at 4ax.com>... > I am very much interested if you can duplicate the 'solution' I > managed to find to get the cvs ls command working on our system: > Do as follows: > Check out CVSROOT > Edit the loginfo file by removing most of the comment lines from it. > Then commit the loginfo file > Finally retry the previously nonworking cvs ls command. > > In my case once I had removed the last 4-5 lines of comments cvs ls > started working like it should. > I have absolutely no clue as to why this happened in the fist place, > but for my server it did work. We are using build 57g and mostly the > :ntserver: protocol. > > Please report your finding. > > /Bo > > On Mon, 23 Sep 2002 21:17:02 +0200, mister.mandarino at bluemail.ch > wrote: > > >It seems that impersonation through pserver doesn't work well on w2k. > > > >Our server is configured with the LocalSystem account running the cvsnt > >services. > > > >When the "Impersonation enabled" flag is turned on, clients can login but > >cannot execute a "cvs ls", for example, and get an indication that they > >lack permissions to create a tempdir. Because the users can login, the LocalSystem > >has the proper rights and the services that run under it can impersonate > >other users. > > > >However, it seems that creation of the tempdir is attempted by another process. > >In fact, the name of the tempdir includes a PID as part of it. There is > >no process with this PID after the unsuccessful attempt to create the tempdir. > >So it seems that the process exists only for a short time and that it is > >spawned by the cvsnt services. This process seems not to have the proper > >permission to create the tempdir. > > > >On the other hand, when the services run with disabled impersonation (which > >is not recommended for obvious security reasons), clients can login and > >operate normally. > > > >I have seen that other users experienced the same problem, but nobody has > >posted a workaround until now. > > > >Any explanation would be greatly appreciated. > > > > > > > > > /Bo > (Bo Berglund, developer in Sweden)