[gentoo-user] Re: [OT encfs] When encfs gets hungup

[Harry Putnam]

Albert Hopkins <marduk@×××××××××××.org> writes:

> On Friday, July 8 at 11:55 (-0500), Harry Putnam said:
>
> [..]
>> Somehow I managed to really hurt the installation ... here is what I
>> remember having done:
>>
>> Some how I got mixed up when running as root, and attempted to mount a
>> users encfs directory.  (Its a single user machine so it my users
>> directory)
>>
>> That should just fail with some kind of permission error since no one,
>> even root, can mess with someone elses' encfs directory.
>>
> This is not entirely the case.  No one can enter an encfs mount
> (destination) but the person that mounted it (by default), but anyone
> can *mount* the encfs "source" (and thus become the owner of the mount).
> All other Unix permissions are retained.
>
>> But once I'd done that I could no longer even `ls' the subject
>> directory.  Not as user, not as root.  A simple `ls' would totally
>> hang the terminal.
>>
>> Of course I tried to umount but really it never actually mounted.
>>
> It probably *did* mount, but...
>
>> I started getting this error: `Transport endpoint is not connected'

> Usually that means the background process that actually handles the
> enc/dec has died or is otherwise not responding.

>> I could see roots attempt to mount the darn thing in ps wwaux output
>> and killed that pid.
>>
> That's probably why you got the above error.  But technically if you
> just kill the process, the kernel still thinks it's mounted.

>> Eventually (after posting several days ago on encfs list.  I resorted
>> to umounting /home (after full backup of course) and reformatted it.
>>
> That's seems a bit extreme...
>
>> I was then able to deleted encfs_raw and encfs_mnt.
>>
> Did you try simply rebooting or manually unmounting?  That's probably
> all that was needed.

Yes, both. First the umounting, then reboot.  So no I don't think it
was all that was needed.

>> But here is the real kicker.  Even after all that, and in fact another
>> full round of mostly the same stuff, including another reformat.  So
>> two reformats and two reboots.  Even with that, I still cannot create a
>> new enc_raw and enc_mount of the same name as the old one.
 
> What do you mean by "cannot"?  Do you get an error?  Does dmesg tell you
> anything?

I meant the earlier behavior would recur, without the `Transport
endpoint is not connected' part.  That is,  mkdir ~/.encjunk ~/.junk

   encfs ~/.encjunk ~/.junk    Would result in completely hung
terminal when I answered the passwd prompt. 

[...]

> If you totally remove the source and target directories, there is no
> other information stored, which allows you to (e.g) encfs directory on a
> vfat-formated USB stick and move it mount it on a different machine.
> All that encfs knows about an encrypted directory is in *one* file on
> the source directory (.encfs6.xml).  Once that file is gone, there is no
> such thing as an encfs.

There must have been plenty of pilot error in the original goings on.
I tried to report it as it actually happened but I must have had some
of it wrong or whatever... because just now, prompted by your input.
(and there have been at least two reboots (as mentioned earlier)) 

I was able to generate the desired mount name with no problems.

So don't have to rework any scripts or continue puzzling over what was
going on.  In other words... as has happened a few other times,
writing about the problem has seemed to cure it..

I'm good to go now ... thanks.