Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm developing a front end to our subversion setup using WebDAV, XSL stylesheets and some php scripts to interface the svn binary. I wrote a simple shell script that sets up a project based on our tech policy (pretty standard stuff). However, the script won't run properly when executed by the apache user _www (OS X server). It complain's about not getting a password for _www. We do authentication through open directory so there are no .htaccess files controlling the authentication.

Can I somehow grant access to _www without having to type a password so that my scripts can run non interactive?

Adding this to Limit didn't help (although, removing the Limit tag altogether from the conf obviously works!):

Require user  _www _www@MYSERVER

It should be noted that _www has recursive ownership rights to directory that holds my repositories.

share|improve this question
up vote 1 down vote accepted

If the subversion repository resides on the same machine as the web server, the solution is fairly simple. You just have to

chown -R _www /path/to/repo

and that should be enough. Make sure the user has read/write access (and execute on the directories). Make sure you access the repository through the file:/// protocol and you will not require a password at all.

If the repository needs to be owned by another user, you could use groups to set the permissions instead.

If you have a remote repository, things become a little more complicated. If that's the case, I'll revise my answer then :)

share|improve this answer
I edited my question a bit to make it clear that _www actually does have ownership rights. Also, removing the Limit tag from the conf obviously makes the script run correctly. However, it's not a very good solution. – macke Nov 13 '09 at 17:06
I missed your note about the file:// protocol, but that fixed the problem of course! =) Thanks a bunch, it works perfectly now! – macke Nov 13 '09 at 17:26

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.