Cheap, un-managed dedicated and virtual servers are now a commodity online. You can get a Linux VPS (128MB / 15GB / OpenVZ) for around £7 per year from the likes of BuyVM, or you can opt for a basic dedicated server (2GB / 500GB / Linux) from OVH for around £40 per year. It’s never been a better time to get into dedicated servers, if that’s your thing.

500GB of storage on-line for £40 per year is a fantastic proposition, much cheaper than Dropbox (although functionally they are quite different) and handy for those who want to share files easily. As a Windows user, I figured it’d be neat to use one of these servers to store rarely used files or ones that didn’t require massively fast access.

My main requirement is that the file share on the server should be able to be mapped as a Windows drive letter, and ideally without any third party software.

Does it work? Sort of. Very slowly.


  • Domestic cable modem line on Telstra in Melbourne suburbs.
  • 25Mbit downstream / 1Mbit upstream.
  • BuyVM 128MB VPS based in Las Vegas.
  • Ubuntu Linux Minimal 12.04.
  • Ping from Melbourne to Las Vegas is 180ms.
  • Server: Followed tutorials in Ubuntu Server Guide – Samba File Server and PPTP Server.

Approach 1: Ubuntu + PPTPD (insecure) VPN + Samba

Before you jump at me I just wanted to test potential throughput with the relatively simple and insecure PPTP protocol to see what potential throughput could be achieved.

The Windows native VPN client connected easily and mapping the drive was simple enough, however directory viewing and initiating copy operations was excruciatingly slow – appearing to hang at the point of initialising.

Once the copy had started, throughput was a miserly 2KB p/sec, rising to a steady 200KB p/sec over the course of a few minutes based on one single large file. Had the transfer been multiple small files, the transfer negotiation and ping delay would have pushed this down massively.

I opted not to try a more secure L2TP based VPN as it was obvious that latency was the performance killer here.

As a proof of concept it does show that you can connect to a internet based Windows share securely without requiring any further software.

Approach 2: Ubuntu + SSH + Samba

You can kludge Windows to connect to a CIFS share via VPN but it does require the use of either Putty or Plink, installation of the Microsoft Windows Loopback Adapter and a network stack tweak to disable Windows SMB attaching to the Loopback Adapter.

I followed the tutorial here – it worked a treat – however I had also made an additional tweak by creating a Scheduled Task batch file that uses Plink to connect to the server automatically and map the drive.

Here’s my Plink command line if anyone may find it useful (combine it into one line):

plink -N -L -N -ssh -pw passwordhere

Performance was much better than the PPTPD solution and transfers had started slowly but  risen to 600KB p/sec (4.8Mbit p/sec within two minutes. Multiple transfers of small files proved yet again to be very slow indeed.

Tests using a media player were adequate once playback had started (after some time), and seeking within a file was reasonable as long as the media player used utilises inaccurate seeking (as in, not pre-buffering the entire file up to the point you wish to play).


Windows Shares (CIFS) over the internet (without spending money) is a pretty poor experience whichever way you cut it. Without opting for commercial software to enable caching and acceleration – the vanilla experience is pretty poor, especially if you want to transfer lots of small files at once. Kinda ironic considering CIFS is an acronym for Common Internet File System.

The problem lies mainly with the roots of CIFS, which is based upon the pre-internet SMB (Server Message Block) protocol designed for low latency local area networks. The protocol is considered to be “chatty”, meaning negotiating operations on files requires a lot of back and forth communications between the client and server, which is exacerbated by the relatively higher latencies experienced on the internet.

Subsequent versions have made progress in mitigating this latency issue but it is still no where near as good as a SSHFS solution (Linux to Linux) or HTTP.

That said, using CIFS over the internet may be fine for playing back long form media or accessing rarely used, medium sized files.


There are third party applications to map network drives online using other protocols, although often they do cost money. I had looked into the freely available (based on Dokan) options for mapping a drive to SSHFS based shares but found that I was receiving peculiar errors when trying to initiate large transfers.

Windows Server offers many solutions such as DFS and BranchCache to enable remote access of Windows shares – however this is an expensive option and is beyond the scope of what I had hoped to have achieved.

Another experiment…

Late addition, but using WebDAV was suggested to me. I used Apache’s WebDAV implementation which is pretty solid and used Microsoft’s native WebDAV support in Windows 7 – sadly performance with this was once again pretty bad, despite WebDAV being designed to work in this environment specifically! The server sent out the files quickly enough, it just seemed like Windows has a very poor WebDAV client library which runs very slowly indeed – not to mention is very quirky, a registry edit is required to get it to work, another to allow medium to large size files. The main issue is with progress dialog boxes appearing to freeze without any progress updates, files are sometimes transferred incomplete but failing silently and multiple small transactions on the connection mentioned above had a transfer rate of around 2KB p/sec. All in all a terrible experience! I’m amazed that this is still the case, in 2013.