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 <bhanupras...@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 <caseyhe...@gmail.com > <mailto:caseyhe...@gmail.com>> wrote: > On May 12, 2020, at 6:27 PM, Daniel Shahaf <d...@daniel.shahaf.name > <mailto:d...@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 >
