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

Keyboard and Mouse Microstutters with a Dell Latitude Notebook

I’ve been having a weird microstuttering issue with my Dell notebook, running Windows 10. The symptoms are input from the keyboard or the mouse hanging for about a half second to a second every 1-2 minutes. When this happens, I am unable to move the mouse.

Rebooting the system did no good, and I found no hints in the event log.

Through trial and error I think I have found a workaround: Disconnect all USB devices, then reconnect them.

My working theory is that the USB drivers scan for new devices, or are discovering a device as new (there’s no popup though). I wonder if this might be a bad or loose USB plug or something similar.

Anyway. If you have a similar issue, try reconnecting all USB devices. And if you have any idea as to the actual root cause… please leave a comment.

Gigabyte OSD_Sidekick: “Please check if your USB cable is connected”

I wanted to find out what firmware my Gigabyte M32Q screen was running, and update it if necessary. The software used to do so is called OSD_Sidekick. Installation was a bit odd – it froze my PC for a few moments. But the installation did finish.

However, OSD_Sidekick.exe wouldn’t recognize my M32Q, instead displaying the error message “Please check if your USB cable is connected”. I quickly verified that my USB cable was, indeed, connected. I know it works too, because I have an iPad and an iPhone connected to my M32Q’s USB hub.

A reboot did not help.

Googling the issue, I found that some people recommended replacing the USB cable. I thought this would be odd, as I am using the USB cable included with the M32Q. On a whim, I disconnected my USB cable and reconnected it. I unplugged it from the rear of my PC, as that’s slightly easier; I am not sure if it matters.

And lo and behold, OSD_Sidekick recognized my M32Q.

My theory is that the USB driver OSD Sidekick installed needed a reconnect event to “discover” the screen.

As an aside, it turned out that my M32Q is already on the latest firmware. However, OSD_Sidekick may still come in handy – apparently you can change most, if not all, settings of the screen without the fiddly rear joystick.

MP3 Songs on iPhone greyed out; “This song is not currently available in your country or region” error message

iPhone sync has always been a little wonky, but today I discovered this gem. A few audio tracks showed up on my iPhone but were greyed out; tapping them resulted in an “This song is not currently available in your country or region” error message.

What worked for me was to turn off “Sync with this iPhone over Wi-Fi” in iTunes and click the sync button. Lo and behold, the missing mp3 songs were transferred to my iPhone and I can now play them.

This happened on Windows 10, but may apply to Mac OS as well.

I’m using iTunes and an iPhone SE (2020 model) with iOS 15.1.

iPhone: Can’t Enter Recovery Mode

I was just trying to factory reset an old iPhone 6S, following these instructions provided by Apple. However, try as I might, the phone would just reboot.

Turns out my notebook’s USB port I was using to connect the iPhone 6S for doesn’t provide enough voltage and is thus ignored by the iPhone. I think this is so the phone doesn’t risk running out of power while updating.

The solution was to use a powered USB hub.

Gnucash: “Install Online Price Retrieval for GnuCash” results in “Access is Denied” error

When I tried to install Stock market price retrieval for Gnucash – via the included script – I was presented with an “msxml3.dll: Access is denied” error.

At first, I thought this was an UAC problem and reinstalled GnuCash outside the Program Files directory, but this did not help.

The solution turned out to be reasonably easy. In “Internet Options”, go to Security -> Custom Level:

Then, scroll down to “Access data across domains” and set it to “Enabled”:

The installation should now work.

Once it completed (it takes quite a while), I reset “Access data across domains” to “Disabled”.

Windows 10 “Type here to search” Search in Taskbar not working

This is going to be a little more unspecific than I usually like my posts, but it took me a while to fix and I didn’t document well. My apologies, I hope this still helps.

I recently had the issue that, when clicking on the “Type here to search” search box in the taskbar of Windows 10, the little window that pops up stayed completely blank. There was a small activity indicator at the top, and eventually it displayed a magnifying glass icon. That’s it.

Microsoft has broken that function in the past, but none of the workarounds – like disabling Bing integration – worked for me. It was also not a problem with the Search service itself, which seemed to be running and functioning just fine. This was clearly something else.

I tried the Windows repair commands, DISM and SFC, but to no avail. The issue would just not come back. I had almost resolved myself to not being able to fix this one without a fresh install, when I got on the right track. In my Event log, I noticed these errors:

Faulting application name: smartscreen.exe, version: 10.0.19041.264, time stamp: 0x36c2907c
Faulting module name: ucrtbase.dll, version: 10.0.19041.423, time stamp: 0xccf6a09c
Exception code: 0xc0000409
Fault offset: 0x000000000007284e
Faulting process id: 0x588
Faulting application start time: 0x01d674e5ef723b48
Faulting application path: C:\Windows\System32\smartscreen.exe
Faulting module path: C:\WINDOWS\System32\ucrtbase.dll
Report Id: 5e47b671-8ea4-47d0-b871-9df47f437410
Faulting package full name:
Faulting package-relative application ID:

It turns out that ucrtbase.dll is a “universal c runtime” library, which is installed with the Visual C++ redistributable package. Which, these days, is also installed by Windows itself.

I checked my installed Apps, and found I had not only the Windows SDK – I used some of its debug tools in the past – but about 30 different versions of the Visual C++ redistributable package. I decided this was entirely too many, uninstalled them all, reinstalled the current version.

Yet the problem still remained.

More out a habit of trial and error than anything else, I re-ran the Repair commands. This time, they found – and repaired – about three dozen files. A reboot later, my search box is working perfectly again.

I am not entirely sure if removing all the C++ packages was the thing that really helped, but appears like that’s the case. As always, since I found no real help on Google, I decided to post this. Hopefully it’ll help someone else out there, some day.

Windows 10: Microfreezes in Games

For the past few weeks, I noticed microfreezes or microstutters in games. Gameplay would “halt” for maybe half a second, then resume normally.

This affected multiple games, so I knew it was a problem with my PC. I checked everything I could – deinstalled applications, made sure nothing “weird” ran in the background, checked the logs, and tried to catch one of the freezes with resource monitors. No luck. I also ruled out thermal issues.

In the end, I found the cause by sheer luck: I noticed that every time I had one of those stutters or microfreezes, my desktop wallpaper on my off-hand screen would change. I disabled wallpaper slideshows and lo and behold: No more microfreezes.

Why this feature would cause a problem, I have no idea. It certainly hasn’t been an issue in the past. I am not sure if it’s related to the Windows 10 “May Update” – I think the freezes occurred before I installed that update.

System: AMD Ryzen 3900X, NVIDIA GTX 1080, Windows 10 Professional 64bit. All patches and drivers up-to-date.

WordPress: Site not Secure despite SSL Certificate

I’ve recently migrated all my sites to use SSL (I know, it’s long overdue) and despite the SSL-Certificates being valid and working, Chrome and Firefox would show my sites as “not secure”. (No padlock icon.)

After some digging, I discovered that WordPress really doesn’t play very nicely with SSL. Lots of themes, plugins, etc will use hard-coded or generated, absolute, http:// URLs, with no regards to what the site is actually using. Worse, posts may include absolute URLs in links to content.

Instead of fixing all themes, plugins, and content manually (or with a clever script), one easy solution is to include the following line in your .htaccess:

Header always set Content-Security-Policy "upgrade-insecure-requests;"

This will cause the users’ browsers to convert all insecure http-Links to https automatically. So far, it seems to work perfectly fine.