[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Permission denied error with mod_dav_svn

From: Edelson, Justin <Justin.Edelson_at_mtvn.com>
Date: 2006-07-27 17:07:48 CEST

I actually went so far as to download, compile, and install apr and
apr-util separately, then apache (telling it to use the installed apr
and apr-util) and then subversion (telling it to use the installed apxs,
apr and apr-util).
 
When doing this, apr and apr-util were installed into /usr/local/apr
 
Specific version numbers:
apr 1.2.7
apr-util 1.2.7
apache 2.2.2
subversion 1.3.2

________________________________

From: Tim Berglund [mailto:tlberglund@gmail.com]
Sent: Thursday, July 27, 2006 10:49 AM
To: Edelson, Justin
Cc: users@subversion.tigris.org
Subject: Re: Permission denied error with mod_dav_svn

Justin:

This was precisely my experience when installing an instance of
Subversion at work under Fedora Core 3. I was able to get Apache 2.0.x
and Subversion 1.0.x compiled and happy there. Then when I put Fedore
Core 5 on a personal server, I figured since everything came bundled it
should work out of the box and any problems must be my fault. So naive.
:)

I actually tried compiling Apache and Subversion together just before
bed last night, and ran into trouble, so I backed off and figured I'd
see if I could solve the main problem by way of a frontal assault. But
perhaps I should try compiling again. To be clear, apr and apr-util
should be included in the main Apache source distribution, right? I was
having trouble getting Subversion's configure script to recognize where
those two directories were located. Is the best approach to point
Subversion's configure at the relevant apxs script, or individually at
the apr and apr-util directories?

Tim

On 7/27/06, Edelson, Justin <Justin.Edelson@mtvn.com> wrote:

        I can't speak to what's provided by Fedora, but if you're going
to be compiling subversion, it's critical that it be compiled against
the same version of APR as Apache. Failure to do so resulted, for me at
least, with all sorts of non-intuitive error messages, including (I
believe) permission denied.
         
        Ultimately, the easiest course of action for me was to
compile/install apr, apr-util, apache, and then subversion, ensuring
that the appropriate flags were passed to each configure script with the
appropriate installation path from the prior step.
         
        I'm sure some of this could have been avoided.

________________________________

        
        
        From: Tim Berglund [mailto: tlberglund@gmail.com
<mailto:tlberglund@gmail.com> ]
        
        Sent: Thursday, July 27, 2006 10:30 AM
        To: Edelson, Justin
        Cc: users@subversion.tigris.org
        Subject: Re: Permission denied error with mod_dav_svn
        
        
        
        Justin:
        
        Initially I didn't compile either one; they were just what I got
from the Fedora install and later updated by yum. Last night I did
compile and install Subversion, but "make install" didn't appear to
provide new copies of mod_dav_svn.so anywhere. In any case, the behavior
was the same before and after.
        
        Tim
        
        
        
        On 7/27/06, Edelson, Justin <Justin.Edelson@mtvn.com> wrote:

                Did you compile Apache and/or Subversion yourself?

________________________________

                From: Tim Berglund [mailto: tlberglund@gmail.com
<mailto:tlberglund@gmail.com> ]
                Sent: Thursday, July 27, 2006 10:10 AM
                To: users@subversion.tigris.org
                Subject: Permission denied error with mod_dav_svn
                
                
                
                I'm running Apache 2.2.2 and Subversion 1.3.2 on Fedora
Core 5. I am attempting to use mod_dav_svn to access a Subversion
repository, but I'm getting permission deined errors that don't seem to
make sense.
                
                The relevant part of httpd.conf:
                <Location /svn/web>
                   DAV svn
                   SVNPath /var/svn/web
                </Location>
                
                The relevant part of Apache's error log:
                [Thu Jul 27 07:22:03 2006] [error] [client
64.81.101.167] (20014)Internal error: Can't open file
'/var/svn/web/format': Permission denied
                [Thu Jul 27 07:22:03 2006] [error] [client
64.81.101.167] Could not fetch resource information. [500, #0]
                [Thu Jul 27 07:22:03 2006] [error] [client
64.81.101.167] Could not open the requested SVN filesystem [500, #13]
                [Thu Jul 27 07:22:03 2006] [error] [client
64.81.101.167] Could not open the requested SVN filesystem [500, #13]
                
                What I see in the browser window when I hit
http://server/svn/web:
                <D:error>
                   <C:error/>
                   <m:human-readable errcode="13">Could not open the
requested SVN filesystem</m:human-readable>
                </D:error>
                
                All of the SVN repository files are owned by
apache:apache, which is consistent with the values of the User and Group
directives in httpd.conf (Apache is running as the user "apache"). Just
to take the really big hammer to the problem, I made gave
/var/svn/web/format permissions of 666, and gave /var, /var/svn/ and
/var/svn/web permissions of 777. No dice. I'm thinking the problem isn't
really a matter of permissions.
                
                I saw a similar error reported at
http://svn.haxx.se/users/archive-2004-12/0345.shtml, but there didn't
seem to be a solution posted there.
                Any ideas? I know I've got a lot of details posted here;
sorry for the big dump. I'm most grateful for any suggestions you can
provide.
                
                Warmly,
                Tim Berglund
                
Received on Thu Jul 27 17:10:12 2006

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.