Storage Made Easy Forums
Start New Topic
Storage Made Easy General
Storage Made Easy iPhone / iPad Application
SME Windows Desktop and Windows 8 Surface Tablet
SME Linux Cloud Drive
SME Firefox Add-In's
SME Mac Virtual Drive & Mac Tools
Protocol Adaptors (FTP, Dav, S3)
Personal Cloud Appliance
SME Direct Applications
Storage Made Easy
Start New Topic
Linux tools are still not up to scratch
Username or Email
Forgot your password?
Keep me logged in
Create an account
SME Linux Cloud Drive
This is just some general feedback and comments based on my personal testing, which I hope will be useful to the devs, and anyone else who is thinking about using SME on Linux.
First - to the developers - I sincerely appreciate that you have made any effort at all to make your product work with Linux, that is more than most other service providers with similar offerings. The down side is that IMO the tools still have a long way to go, functionally speaking, before I would consider using them to support business critical functions.
My use case : I am a security professional, currently a 1-man-band but with ambitions to expand. What I essentially wanted was a kind of cloud based NAS that I could use in place of a company file server. I have high security requirements, including zero knowledge / client side encryption of any files uploaded to the service - this immediately ruled out the likes of dropbox, onedrive, S3, etc. I looked at services like sync.com (no linux support), spideroak (not really zero knowledge), and tressorit (too expensive), but couldn't find anything that met my needs. When I stumbled across SME, I thought I was onto a winner.
I decided to give it a spin, and downloaded the personal edition. I am aware that the free version lacks some functionality, but I wasn't willing to pay for it before I knew it would do what I wanted. Now I am glad that I didn't, because frankly it doesn't live up to my expectations.
Firstly problem - I am running Manjaro (an Arch derivative) as my Linux distro. I was not impressed to see there is no Arch support, these days you can't get by just supporting ubuntu and fedora (or debian and centos), especially not for something which is supposed to be an end-user application.
Despite the lack of official support, I was able to get the linux clients going on my system. Please take note devs - it wouldn't take a huge amount of effort on your part to make an Arch package available:
Download the .deb, extract this with "ar xv <pkgfile.deb>
From this you will get 3 files, you need to untar data.tar.gz (tar -zxvf data.tar.gz), it will extract into ./usr, so probably don't run this as root in /.
sudo cp -a ./usr/share/* /usr/share
sudo cp ./usr/bin/smemount /usr/bin
Use pamac to install perl-fuse and perl-xml-simple
perl-mknod isnt in the repos or in AUR, install via CPAN, or the source is actually in the data tarball, extracts to /usr/share/sme_install
Use pamac to install libappindicator-gtk2
qmake-qt4 && make
cp smeclient /usr/bin
sudo cd ../smeexplorer
qmake-qt4 && make
sudo cp smeexplorer /usr/bin
qmake-qt4 && make
sudo cp smesynccenter /usr/bin
Once the binaries we compiled, they seemed to work fine on my system. I soon discovered there are few annoying bugs:
The CLI help for smemount says to specify credentials file with --credentials=/path/to/file - this is wrong. I had to read the perl script to work out that the correct syntax is --credentials:/path/to/file. If you use =, the mount command fails silently, although it does create a log file.
Trying to open files in smeexplorer fails silently. If I ran the program from the console I saw in the debug log that it is trying to use gnome-open or kde-open - both are deprecated, xdg-open is the new standard, I worked around this by symlinking gnome-open to xdg-open
openoffice can't save files it is working on if opened via smemount, for some reason it sees it's own lock file and thinks another instance of the program has the file open.
There are also a couple of security issues:
All connections for some reason default to http, you have to manually specifcy to connect to
if you dont want everythign transmitted over http. Sersiously, why is this even an option? https should not only be the default, it should be mandatory.
If you specify the credentials on the command line, the will be visible in the process list
The file encryption password is stored in clear text in Storagemadeeasy_drive.conf - not even hidden in a dotfile. Not sure why, the user password is stored as an base64 aes encrypted string.
I probably could have lived with all those things, there were work arounds or other mitigating factors. Unfortunately, once I got to actually using the tools, I found there are some deal breaking limitations:
The sync tool doesn't work with encrypted files at all - so it's essentially useless.
If you open a file with smeexplorer, any changes you make aren't uploaded to the cloud - so it's essentially useless.
smemount/smeclient has no way to upload or create a new encrypted file. Even if you specify the password, it only applies to download, any new files will be uploaded unencrypted - so its essentially useless.
This means the only possible work flow if you require file encryption is:
Create the new file in whatever program, save it to your local disk.
Close the program
Upload the file using smeexplorer, specify the desired password
mount the location you uploaded the file to using smemount
open the file in the original program from the smemount point
Honestly, with that much stuffing around involved, you might as well just use the web file manager and stick to downloading/editing/uploading. However, if it comes to that, the sync.com web UI is much, much, better. If nothing else, at least with sync.com all the encryption is transparent and doesn't require manually typing a password for every file.
FWIW, when I tested the windows file explorer client, it DID auto-sync any changes when an open file was saved. If I that worked on the Linux client, it might be passable. As it is, it's just too hard to use. Also, I haven't tested the paid-for windows tools. I realise they're probably much better than the Linux ones, but I have little need for Windows on a day to day basis. They are not going to be any use to me.
Anyway, after all that I think I am going to have to find another solution, maybe I will just suck it up and use sync.com via the web UI.
To the Devs - points for trying, but I think you need to take Linux more seriously and more tightly integrate the file encryption if you want IT pros to consider using your product.
Firstly thanks for the detailed email. We really appreciate it.
Now let me address some of your concerns / questions
I think you are testing using an old version (4.5.3 from April 2016) and I think the reason for this is the page where you can access our Linux tools was stale or has been reverted. It listed an old version. The Linux tools are currently on version 4.8.3 (updated March 2017) and this addresses some of your issues and we have
updated the page
The versions released since the version you tested:
1) v4.7.5 - a lot of fixes and improved encryption. Completed in Sep 2016
2) v4.7.6 - fixed couple bug. Completed in Jan 2017
3) v4.8.3 - added support of 2fa. Completed in Mar 2017
Specifically on the issues you reported:
> The CLI help for smemount says to specify credentials file with --credentials=/path/to/file - this is wrong. I had to read the perl script to work out that the correct syntax is --credentials:/path/to/file.
This was a bug and it was fixed in l4,8,3
> If I ran the program from the console I saw in the debug log that it is trying to use gnome-open or kde-open - both are deprecated, xdg-open is the new standard
There is no such problem in the Linux distros that we support now but thanks for pointing this out and we will fix in the next revision.
> All connections for some reason default to http, you have to manually specifcy to connect to
This should be fine in the current version. We used to allow HTTP, because there was a bug related to HTTPS in the linux library that we used within the App to send requests.
> The sync tool doesn't work with encrypted files at all - so it's essentially useless
The free version not allow to work with encrypted files. Only the Pro version allows to work with encrypted files.
> If you open a file with smeexplorer, any changes you make aren't uploaded to the cloud
Yes, this is an issue. We are still looking for an elegant solution. We did manage to solve a similar issue on our windows explorer but that is because of some standard hooks that are not present in Linux.
> smemount/smeclient has no way to upload or create a new encrypted file.
It is a drive so there is no way to determine whether to upload encrypted or not. It is an all or nothing solution. Perhaps a global mode that is set in options ?
> Even if you specify the password, it only applies to download, any new files will be uploaded unencrypted
This is not the case in the current version. It was resolve some time ago. If file encrypted and user try to edit/replace it then we save it with the same encryption key. If we don't know the encryption key then we will ask user to provide and encryption key.
If you use team encryption then this works explicitly based on initial IAM request or all files and you don't need to configure/change anything in the clients as the keys are stored, encrypted, server-side.
Wow, well thanks for such a detailed and prompt reply, it's nice to see a vendor paying attention to their user forums for a change.
It's a shame that I went through all that trouble and wrote all that criticism for a version of the tools which wasn't current - though I do admit I was a bit disappointed when I first downloaded them to see that the "latest version" seemed to be over a year old. Also glad to hear many of the issues I identified have already been sorted.
Regarding xdg-open, the issue is less to do with distribution and more about which desktop environment you're using. I am using xfce so I dont have gnome-open of kde-open, the same will be true to anyone using xfce, or some other DE, regardless of their distro, so you should definitely switch to xdg-open for more broad compatibility.
As far as the encryption goes, are you saying that the pro version of the linux tools will sync encrypted files? If so, then that is definitely a big selling point for me as ideally using the sync would be my primary way to interact with the service. I do like the idea of working with a virtual drive / FUSE mount, but without some way to auto-encrypt new files copied into the space this is a non-starter for me. Your suggestion about some kind of global option is probably worth implementing IMO - if you could set a common passphrase to encrypt every file in the mount point, so that new files copied or saved there are automatically encrypted with the same key, that would go a long way to fixing the problem I think.
Overall I think the file encryption user experience needs to be a bit more seamless. I appreciate the granularity you get with being able to set a different password for individual files, but in practice no one is going to do that because it's too many passwords to remember, I expect most users will have a single password they use for every file, or at best a small set of passwords for different clients' info or something. I think a better solution would be using randomly generated keys and storing them in a database which is encrypted to the user's password or something. Then once the user is logged in the client can download the db, decrypt it, and access all their files.
Anyway thanks for taking the time to respond to my comments. Is it possible to get a trial of the pro-tools on the individual plan (similar to there is for the business plans)? I'm definitely interested to see if the newer/full versions will meet my needs, but I am not about to pay for them without testing them first.
You can sign up for the business plan to get access to trial versions of the pro tools.
Web Address (URL)
Paste an image URL here:
If your URL is correct, you'll see an image preview here Large images may take a few minutes to appear.
Remember: Using others' images on the web without their permission may be bad manners, or worse, copyright infringement.
Unsupported photo file type. Please upload the file as a post attachment instead.
Share this post
Link to post
Share on other sites
You need to be logged in to send an email.
Forgot your password?
Keep me logged in
Forum Terms & Rules
Smileys & People
Food & Drink
Travel & Places
Enter your video clip URL below:
Supported videos include:
Please paste your code into the box below: