issues with permissions and Virtualmin's svn plug-in

On a plain Debian server with two virtual servers set up (a main site at and a dev site set up as a subserver at, errors started appearing when attempting to commit files via svn. Here's an example of one of the errors:

Commit failed (details follow):
access to
access to
'/svn/private/trunk/sites/all/themes/private/views-view--delivery.tpl.php' forbidden

Sensitive names have been replaced with "private".

After fiddling with permissions for a while and coming up empty, I ended up exporting the repo, deleting it from the server (which I had to do manually since the "Delete" button didn't do anything and no error was shown) and re-importing it. I was then able to commit files as expected.

This isn't the first time this has happened. In all cases, developers are trying to commit over https (e.g. and the intervention listed above has been the only way I know to fix it (other than deleting the entire virtual server and re-creating it, which isn't an option most of the time).



Since access to the repository is done via HTTPS, are any useful entries being recorded in Apache's access and error logs at the time of commit attempt? Those might tell more than the errors on client-side.

Does the "Fix Permissions" button help in this case?

Also, are any developers accessing the repo via some other method, like SSH?

No, the "fix permissions" button didn't help. I'll update this issue when I see the issue occur again.

I think I have the same problem, in my case the superuser can access the repository but the email-ftp users can't, I was playing around and I find something strange, I found that if you delete the email-ftp user in the password file located at /home/VIRTUALSERVER/etc/svn.basic.passwd and then recreate it with the same password using the following command "htpasswd -mb /home/VIRTUALSERVER/etc/svn.basic.passwd USERNAME PASSWORD" it works perfectly, also works with -mdb, -msb, -sdb, -sb, -db and -msdb didnt work with -pb

I check and the password created by virtualmin is encripted, then I can asume that the problem isn't in the encription, It can be that the password isn't set correctly in the password file?