“Access Denied” Errors with TortoiseSVN on Samba

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.

SVN Stalling

I had this weird problem where my svn would upload a few MB and then stall and timeout. At first I of course suspected a problem with either svn on the server, the apache, or tortoisesvn. I tried CPU affinity settings, Apache settings – nothing I did helped, including updating to latest patchlevel etc. After some trial and error, I found out that restarting my OpenVPN – which transports my svn traffic to ensure it is encrypted – seemed to help for a few moments.

After the timeouts, there were actually moments where I couldn’t connect to my server at all. Restarting the OpenVPN connection alleviated that problem.

So checking the log, I found that the openvpn reconnected when it timed out, and I saw this message:

Apr 3 01:14:15 corinth ovpn-server[1050]: MULTI: new connection by client ‘ghostwheel’ will cause previous active sessions by this client to be dropped. Remember to use the –duplicate-cn option if you want multiple clients using the same certificate or username to concurrently connect.

Aha! What IP was I coming in from?

Apr 3 01:14:15 corinth ovpn-server[1050]: MULTI: Learn: 172.16.0.6 -> ghostwheel/80.187.98.92:10654

And that resolves to an DTAG hostname:

# host 80.187.98.92
92.98.187.80.in-addr.arpa domain name pointer tmo-098-92.customers.d1-online.com.

So the solution of the problem was after all quite simple: Another machine was basically kicking me out of my VPN. And yes, I remembered that my girlfriend borrowed my Samsung NC 10 – and she probably left it running when she went to work. I hadn’t remembered that I had just copied the VPN config including certificate when I set up my home PC, but of course it was easy to fix.