“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.


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:

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.

Synology Cloudstation Pauses and Does Not Sync

The Problem:

My Cloudstation app stopped working and would not synchronize files anymore. This happened both on Windows, and on Mac.


It seemed like the app was either permanently in a “connecting” state, or pausing itself.

The solution:

It turns out that my Quick Connect became disabled at some point. I am not sure how or why; it had no account associated. I re-added that and enabled Quick Connect on my DiskStation, and Cloudstation started working again. This was especially odd because in the Cloudstation settings on my Diskstation, the status “Healthy” was displayed.

Mac OS X: Time Machine Backup Slow / Stuck

I just noticed that my time machine backup (to a Synology NAS) was slow. As in… single-digit kilobytes per second, and then it got stuck completely. At first I thought this may be an issue with the Synology drive, but this turned out not to be true. In the log file of the Mac, I found a large number of these lines:

Sep 20 20:27:01 Ascalon.local mdworker[20883]: (Warning) Import: Bad path:

(Ascalon is the name of my Macbook Air.)

This seemed to be indicative of a filesystem error, but this was not the case.

It turned out that in my case the offending drive was an old Kindle I had connected to my Macbook to charge – it does mount as a USB drive, similar to a flash memory stick. Anyway, once unplugged the Time Machine backup ran as fast as always.

I should probably note that the Kindle itself is not defective – disk scans give it a clean bill of health. So I have to assume that something in its folder structure is not compatible with Time Machine. Unfortunately I never connected the Kindle to my Macbook Air before, so I can’t say if this is a general issue or a new bug of some sort.

Anyway, solution in this case: Unplug all USB drives one after the other, restart the Time Machine backup after each one to see which one offends, and then deal with that. You can use the disk check utility on your Mac, but please make sure you know what you are doing and do not accidentally erase it. (The Apple Knowledge Base is probably a good place to start.)