Precautions
John - DataStorageUnit - Owner
Note from the author of EncFS:
"The control file contains the filesystem parameters, in addition to
encrypted key data which is different for every filesystem.. You need
both the password and this control file in order to access the data.
If you loose either one, there isn't anything I can do to help"
Just wanted to mention that someone pointed out to me the importance
of having a backup copy of your control file handy in case something
goes wrong. Also, please keep in mind that I am in no way an expert
in all the possible backup methods/softwares that can be used with
this service. Be sure you are familiar with the method you are using
and always follow best practices by keeping your data in multiple
locations.
knnniggett
In case someone out there actually uses the dsu_backup.sh script, it
does create a backup copy of the control file, .encfs5, for you and
places it under your home folder under a folder called
"encfs_backup". Note that the control file itself is hidden so for
anyone who wishes to see the file you will need to do an "ls -a" from
the command line or tell your file manager gui (e.g. nautilus) to show
hidden files.
On Jan 29, 9:37 am, John - DataStorageUnit - Owner
knnniggett
of the .encfs5 control file onto the home folder of your *local* PC.
marlar
> > > of having a backup copy of your control file handy in case something
> > > goes wrong.
I was me who had this incidense. I had uploaded 4+ GB to my new
account over a quite slow ADSL connection. I had mounted the encrypted
filesystem locally on the server and I realized that during the upload
(which took many, many hours) the folder was actually accessible to
anyone with administrator privileges. With my data not being
especially interesting to others it was not really a problem, but I
thought I would be interesting to try and mount the encfs remotely
over ssh instead, in which case the files are totally inaccessible
even for root.
And so I did. It went ok, although I was puzzled by encfs saying that
it couldn't read the control file. But I entered the password and
everything seemed fine. Well, except that the mounted (unencrypted)
folder was empty!
I unmounted and logged in again with ssh. I was calmed by seeing all
my files in good shape (albeit encrypted) in the raw folder so I
mounted the filesystem ... and found to my despair my unencrypted
folder without content.
At first I thought it was the process itself of mounting over ssh the
filesystem which was created locally that casued the problem. But
after some investigation I found that it was my version being older
than the one on the server. While 1.5 is compatible with the control
files from older versions the opposite is not the case. So my version
1.4 couldn't understand the xml file and instead of backing out or
asking me what to do, it recreated the file rightaway. Making the old
file - and thus all my protected stuff - out of reach forever!!!
Had I just backed up the control file I could regain access, but I
didn't know about the existence of it beforehand. When creating the
filesystem Encfs only talks about not forgetting the password. It does
mention the control file at all. Bad!
Ok, my backup is lost, but it's not a big issue since I have the
originals here (in several locations). It's just that I have to upload
4+ GB again :-)
Just for the record, I found a way to circumvent the version problem:
I first created the encrypted filesystem over SSH with my version and
then mounted it locally. Encfs 1.5 reads older versions without
problems and - more important - does not alter the control file. So
now I can mount it both locally and remotely, depending on how
paranoid I feel :-)
Regards,
Martin
knnniggett
lost your data.
According to the encfs website, they changed the name of the control
file from .encfs5 to .encfs6.xml when they went from version 1.4.x to
1.5.x.
I bet that if you ssh in to your account and delete the
newer .encfs6.xml file (note that "." files appear hidden in Linux),
then you may be able to read your encrypted data again (I'm thinking
the older .encfs5 control file is still there).
Anyway, thanks for the post because I didn't realize that the authors
of encfs made that change (apparently I'm using encfs 1.4 as well). I
will need to make some changes to my backup script to account for
this.
knnniggett
it.
And I think I got that backwards... try renaming the .encfs5 file
to .encfs5.bak or something and see if your data reappears.
marlar
My version 1.4.2 does in fact call the file encfs6.xml. Maybe it
changed already from 1.4 to 1.4.x.
Have you checked the filename used by your version?
knnniggett
fuse-encfs-1.4.1-1.el5.rf
Looks like I'm using 1.4.1. It uses .encfs5 for a control file, and
it is a binary file (i.e. pre-xml).
If you ssh into datastorage unit and do an "ls -a" do you see more
than one control file?
If you do then you should be able to recover your files once you
figure out the right one to use.
If not, perhaps John might have captured the control file you need on
a backup. Just trying to help here.
marlar
There is only one control file in the folder. And John have already
looked for a backup, but since my account was created only 1 day
before the incident, there was no backup yet.
Thanks for your help though! But I have given up and deleted the
folder. Will just upload again.
John - DataStorageUnit - Owner
whether or not they may be affected by this issue and would like to
test by renaming a large folder... or whatever kind of test they
think they should try, I would be more than happy to create a backup
copy of your files before you begin this test. This way, if something
goes wrong I can copy back your data set as it was just before your
change. Also, don't worry if this puts you over your quota for now, I
can up your quota for a short period of time to let you test this
particular issue with no worries of cost. I normally do backups
somewhere in the neighborhood of once per week...but if you want to
stop your uploads, unmount your encfs folder, and then shoot me a
quick email that you want a copy of your home folder made right
then...just let me know. I won't hold onto this copy forever...but I
can keep it for a few days at least.
Martin Larsen
I am a but unsure which problem you are referring to. Is it the one with
using a different version of EncFS over SSH, or the one with a size
mismatch after renaming a big folder?
I did a rename accidentially yesterday, it took a long time, but I let
it finish and there were no problems. As I understand it, the renaming
problem stems from interrupting an ongoing rename.
Martin
John Wooton
Martin Larsen
> I'm not referring to any problem in particular really...basically just
> letting everyone know that if they want to test any potential
> concerns, I would be glad to offer expanding storage temporarily in
> order to allow a full backup copy of their files to be made before
> they test any possible theories.
I would like to test the rename problems since I have just uploaded 72
GB worth of data over a slow connection. It took nearly one month! And I
would not like having to upload all that again, so it would be nice to
test if I can use the rename command safely or if I have to stay away
from using the command at all.
I guess you need to backup the encrypted folder, right?
Regards,
Martin