I just had my networking team share their configs with me and it turns
out they enabled a bunch of "security features" a couple days ago. This
includes severely limiting which HTTP methods were allowed through to
my server, which I believe may be the root cause here. Disabling their
update fixed all the problems.
Thank you so much for the help.
-Casey
> On May 13, 2020, at 11:35 AM, Bhanu Prasad <bhanuprasad9_at_gmail.com> wrote:
>
> Also from OS standpoint if you are running httpd on a Linux server and SE-Linux is turned on [getenforce], Please verify the the context on the directory.
>
> run the below command to see if the contexts are uniform, if indeed you are running selinux.
> # ls -lZ <dir>
> # getenforce #to check if selinux is enabled#
>
>
> On Wed, May 13, 2020 at 2:06 PM Casey Heney <caseyheney_at_gmail.com <mailto:caseyheney_at_gmail.com>> wrote:
> On May 12, 2020, at 6:27 PM, Daniel Shahaf <d.s_at_daniel.shahaf.name <mailto:d.s_at_daniel.shahaf.name>> wrote:
> > Casey Heney wrote on Tue, 12 May 2020 17:23 -0700:
> >> Commit failed (details follow):
> >> Changing directory '/Users/casey/Documents/repo/trunk/docroot/new-dir'
> >> is forbidden by the server
> >> Access to
> >> '/!svn/wrk/cfa651e5-5850-4325-a441-1b5f8f37b3ea/trunk/docroot/new-dir'
> >> forbidden
> >
> > The error code wasn't printed, I see, but it's E195023.
> >
> >> Committing new or modified files works just fine. I can clone a
> >> directory with a new name and commit that. I can also commit deletes of
> >> directories. The problem is just with committing new directories. I
> >> have also tried logging in to the server via Terminal and committing
> >> new folders directly on the server filesystem itself, and that does in
> >> fact work, so I believe the issue is with apache.
> >
> > To be clear, did you run «svn mkdir file:///path/to/repo/foo/bar» or
> > «command mkdir /path/to/repo/foo/bar»? I think you meant the former,
> > but just to make sure.
> >
> > As you say, file:// doesn't use authz.
>
> Confirmed yes. I should have said that file:// works as expected.
>
> >> In an attempt to reduce possible permission issues, I tried updating my
> >> authz file to the following:
> >>
> >> [/]
> >> * = rw
> >
> > Good call. Authz restrictions are indeed one possible cause of E195023.
> >
> > Did you confirm that you modified the correct authz file?
>
> Confirmed yes. I went as far as to use a bad path first to confirm a
> different fail, then switch back to the wide open authz file.
>
> > Another cause of E195023 is HTTP status 403 responses. Those might be
> > returned by some proxy, too. Might that be the unknown recent change?
>
> I will follow up with my networking guys to see if any of them fess up
> to making any unauthorized changes, though I suspect I will hear that
> nothing has changed there either.
>
> I appreciate the quick and thoughtful response nonetheless.
>
> >> Running up against this issue that I can’t find an answer to, I created
> >> an account here hoping someone might have some insight. Being new and
> >> not knowing how this list works exactly, I would appreciate being CC’d
> >> on any replies. Thanks for the help.
> >
> > HTH
> >
> > Daniel
>
Received on 2020-05-13 20:40:46 CEST