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.