I’m presently using Dropbox as a service for quick & easy movement of files between multiple PCs I use. Its copy & paste operation is very intuitive on a Windows PC. I would like the same on the Raspberry Pi (RPi), particularly for moving files from my PC to the RPi. I wanted the same utility on my RPi, but at the same time, I want the Linux command line paradigm supported and not be force to run X Windows on the RPi.
I did some searching and found things like Dropbox’s Linux distribution (which I wasn’t confident would work “out of the box” for the RPi’s ARM architecture, but source is provided), GoodSync or Owncloud (which wouldn’t access my existing Dropbox files but instead create an alternative), python or bash shell based up/down loaders (appears to behave like a simplified FTP tool), or the Secure SHell File System (SSHFS) based approach (the PC’s Dropbox directory is mounted on the RPi).
While the Dropbox’s Linux distribution is likely the ultimate way to go, I didn’t want to commit myself to the effort it would potentially require. I settled on the SSHFS based approach. I’m running my RPi headless and access it via my PC using Cygwin/X and Secure Shell (ssh). With the SSHFS approach, I could make the Dropbox directory available for mounting at boot-up or mount it at will. I only envision using the RPi-based Dropbox when I’m doing development and I will be doing that from my PC. So this SSHFS approach seems fine for the way that I operate.
The SSHFS approach means files will not really be replicated on the RPi, like Dropbox does. The files will reside within my PC’s Dropbox folder (and replicated on my other PCs via the Dropbox service) but accessible by the RPi via the SSHFS file mount. This means I can’t have any applications I run on the RPi depend on files located in its Dropbox directory since it may not be always mounted. I’m OK with this limitation, and in fact is consistent with the ad-hoc purpose I have for the Dropbox directory.
Installation Required on the PC
For me, nothing needs to be done here. I already have Dropbox running on my PC, and via Cygwin/X, I have the foundations required for the host side of the SSHFS solution. If you need help with this, signup for Dropbox here and find out how I’m using Cygwin/X here.
Installation Required on the RPi
On the client side of the solution, you’ll need to install SSHFS and FUSE. FUSE is the user-space filesystem framework and is the foundation on which SSHFS resides. FUSE allows user-space software, SSH in this case, to present a virtual file system interface to the user; something generally only done by the Linux kernel. SSHFS connects to the remote system and provide the look and feel of a regular file system interface for remote files. On the RPi, install SSHFS via the command:
sudo apt-get install sshfs
FUSE appear to be already installed on the RPi or maybe comes with SSHFS. Next you need to add required users to the FUSE usergroup. In my case, that is the user pi. You can see the existing groups pi is part of via the command
groups pi. You can validate that the FUSE user group has been created by using the command
cat /etc/group | grep fuse. To add pi to the FUSE user group, use the command:
sudo gpasswd -a pi fuse
The fuse group lets you limit which users are allowed to use FUSE-based file systems, in my case the Dropbox. This is important because FUSE installs setuid programs, which always carry security implications.
Configuring the Dropbox File System
Now its time to make your Dropbox directory on the RPi, and mount it to the PC’s instance of Dropbox. On the RPi, use this command to create the Dropbox:
The next thing to do is to make sure that you can connect to the PC via ssh. When I installed Cygwin, my focus was on using it as an X Server and making ssh connections from the PC to RPi. I never tried the inverse (connect from the RPi to the PC) and that is what SSHFS is effectively doing. So check for two things:
- Is the ssh server running on the PC? You can check for its status via the command
cygrunsrv -Q sshd. In my case it was running, so its fine.
- Is the port used by the ssh server on the PC open? You’ll need to open SSH port 22 for ssh services to work. You can check its status by attempting to use it. In my case, this was
ssh Jeff@HomePC.home. If this command appears to hang or time out (as it did for me), the port is likely blocked. You’ll need to go to your Windows Firewall and open port 22.
There is another Cygwin sublimity that has to be taken into consideration. When using the Cygwin, Windows drive letters are mapped to a special directory. In my case, the Dropbox directory appears to Cygwin to have the following path:
With this all addressed, reboot the RPi, and then you can now fire up you RPi Dropbox via:
sshfs Jeff@HomePC.home:/cygdrive/c/Users/Jeff/Dropbox ~/Dropbox
After you supply the PC’s password, you should now be able to access the Dropbox directory on the PC. If you wish, you can remove the file system connection to the PC via the command:
fusermount -u ~/Dropbox
This connection will stay established as long as you don’t do the
fusermount -u or reboot the RPi. If you wish to mount the file system upon boot-up, and avoid executing the
sshfs when you log-in, you can follow the procedure outline in the article that initially inspired me: Dropbox on Raspberry Pi via SSHFS
Something to Keep in Mind
While for the most part, moving between Windows/DOS and the Linux file systems isn’t a problem, there is one thing to remember. Windows-based text editors put one set of special characters at the end of lines (i.e. carriage return and line break = ‘\r\n’), while Unix/Linux puts other characters (i.e. line break = ‘\n’). This odd anomaly is normally harmless, but some applications on a Linux cannot understand these characters and can cause Linux to not respond correctly.
The best example of Linux behaving badly (and the only one I know) is the execution of “shebang” or the “#!…” at the top of a bash, python, perl, etc. script. If you edit these files in DOS, then move them to Linux, shebang will stop working. Editing them under DOS is the origin of the problem, since a DOS based text editor will inject the extra carriage return character at the end of the text line.
To fix this problem, you can quickly convert an ASCII text file from DOS format (carriage return and line break) to the Unix format (line break), you can use the tool
dos2unix. Run this utility on the effected file and shebang should work once again.
At its foundation, SSH functions as a protocol for authenticating and encrypting remote shell sessions. SSH can be thought of as much more than just a secure shell. Using SSH’s foundation, SSHFS creates a new capability. To learn more, check out the link SSH: More than secure shell.
Key sources I consulted to write this include: