Tag Archives: tortoisesvn

“Access Denied” Errors with TortoiseSVN on Samba

Posted on by nils
Reply

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

Posted on by nils
Reply

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.