So for some time now I’ve had issues with TortoiseSVN giving me “Access Denied” errors. This mostly happened when I reorganize files, and it was always annoying because it required a nasty workaround – usually, I would have to kill the SVN cache process and clean up my working copy to break write locks.

I finally seem to have found a solution, and apparently it boils down to bugs in Samba. The TortoiseSVN FAQ states:

After upgrading to TortoiseSVN 1.5.x or later, you get a lot of “Access denied” errors for most of the Subversion commands if your working copy is stored on a SAMBA share.

and:

The information we have received suggests that the main problem is fixed in SAMBA 3.2.3. There is a supplementary problem with making files with the svn:needs-lock property read-only. This is reported to be fixed in SAMBA 3.2.6 or 3.3.0.

Now, the issue I was facing was I am running my file shares from a Synology NAS. The cited versions of SAMBA were released a long time ago, and my Synology is, of course, patched to current patch levels.

So I decided to implement the workaround anyway. And lo and behold, it works. After adding:

[global]
delete readonly = yes

To my Synology DiskStation’s smb.conf, I no longer experience the issue.

To edit the file, you need to:

• Enable SSH on your Synology disk station
• Log into your Synology disk station with SSH and your admin account
• Edit the smb.conf file using sudo (“sudo vi /etc/smb/smb.conf”)
• Restart Samba. (I’ll admit, I couldn’t figure out what command to use for that, and I was impatient, so I simply made changes in the Synology GUI and restarted it that way.)
• Deactivate SSH again!

It’s been about a month and I have not had a single “Access Denied” error anymore.

Please note that I do not know if there are any security implications in the workaround.