I am not a full time Chrome OS user -- at least, not yet.
I use a mix of technologies and platforms because I believe in using the right tool for the job. If you are a chef you don't use tongs to cut vegetables or a teapot to deep fry fish. I think you get my point.
While Chrome OS is good enough for me as a writer (I use Google Docs to compose most of my stories), I do most of my early drafts on Sublime Text or similar text editors and all of these files are saved on a central server (more about that later).
On my other systems I can easily access my local server and work on those files, something that until now was not possible on Chromebooks.
Why do I need a file server?
Most modern households, mine among them, have more than one computing device. We have a couple of smartphones, tablets, laptops, PCs and then entertainment boxes like Chromecast, Amazon Fire TV Stick or Roku.
It’s hard to say which device you will be using at any given point; but things get ugly when you don’t have access to the same data across these devices. You will have to copy-paste files from one device to another as you move between them.
That’s where you may think cloud comes into play. Not really. A third party owned public cloud poses two serious problems: 1) it gains access to your data which then becomes subject to known and unknown laws as well as pseudo-property of that provider. That company may block you from accessing your own data or delete it without your consent. 2) There is only so much data you can put on cloud without raising the bill and everything you access consumes bandwidth.
I have around 3.7 TB of data, which includes images, video footage of my shoots, movies, TV shows, music, ebooks, documents, etc. Due to the nature of some of this data I will never put a huge chunk of this data on a public cloud, ever. At the same time I don’t want to waste 5-10 GB of bandwidth every day to access most of this data.
That’s where local file servers comes into play. You can easily set-up a local file server using old hardware and a free of cost Linux operating system. You will have you own ‘cloud’ running in your own house.
You will be able to access any files from all of your devices without having to worry about copying and pasting anymore. All you need to do is to stay within the local network.
Once the local server is mounted on my device it appears as if 4TB of storage has been attached to my Nexus 6, iPad or Macbook Pro.
That’s how I roll.
Until now the only device unable to connect to this grid was my Chromebook, as Chrome OS doesn’t support Samba, SFTP or other such protocols natively. But things have changed thanks to the open nature of Chrome OS and some creative developers.
Let’s connect the Chromebook to the grid
To connect the Chromebook to your local file server, first open the Chrome Web Store and search for the 'sFTP' and ‘Samba’ apps. There are many such apps but I recommend those from ‘eisbahn,’ as they are really mature and work great.
Click on the 'install’ app icon and once installed open the app. You will need to enter the info about your server and when done it will mount your server on Chrome OS and you will be able to access the server right from the file manager of your Chromebook.
I am pretty impressed with the way it works. I have installed some Text Editors on my Chromebooks and can now create drafts for my stories just the way I used to do from my PCs. The files reside on the local server so I can pick them up from any machine. Just right click on any file and choose the ‘Open With’ option on the top. It will show you the installed apps that can handle that file.
I can also play high definition movies right from my server without any latency or quality loss. Just click on the media file you want to play and the embedded player will start the playback.
The same developer has made similar apps for Dropbox, Samba, WebDAV and many such protocols.
If support for Samba, sFTP or Dropbox was holding you back from using a Chromebook, it might be time to give it another look.
Check it out and let us know what you think.
This article is published as part of the IDG Contributor Network. Want to Join?