I'm currently working on an Encfs FileVault replacement
The new solution will actually be integrated into the login window
like FileValut. This will provide a transparent Encfs home dir. No
special hacking on files or startup items, that is the design goal.
> I have been playing around with some of the -o allow_root and -o
> allow_other options be the don't seem to fix the issue. Here are some
> examples maybe Graham knows a trick or two.
Hi Monty
Whilst you may experiment with those options whilst troubleshooting,
I should never recommend them for normal use.
For security: I should never want a process that's not mine to access
my EncFS volume.
If some other process-oriented user ID gains access to my EncFS
volume, then that (other) user might become a possible vector of
attack for hackers.
Security aside: I have the impression that allow_other and allow_root
should be avoided for reasons of stability.
----
Bouncing now between the MacFusion and MacFUSE groups ... re
http://groups.google.com/group/macfuse-devel/browse_frm/thread/
b5e57bfa61927f72
with my thoughts still on *order of events* and maybe *multiplicity*,
have you tried a simple
-s
for single threaded mode?
http://code.google.com/p/macfuse/wiki/OPTIONS
Regards
Graham
> Lock failure on /Users/testencfs/Library/Keychains/
> lck~login.keychain: Operation not permitted
Operation not permitted ... because the file is open or busy?
The "not permitted" seems, to me, different from the examples at
http://groups.google.com/group/macfuse-devel/msg/8b969b65195ff932
-- there, where we expect locks to succeed, they ultimately don't
succeed, but there's no such advice
-- we note the absence of a lock only when we subsequently _look_ for
the lock.
----
Broadening my thoughts:
-- *does* the lock fail?
-- is the file somehow _locked_ _then_ _unlocked_?