Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

If I execute script

#!/usr/bin/expect 
set pass [lindex $argv 0] 
spawn encfs -v  {CRIPT_DIR}  {MNT_DIR} -o nonempty 
expect "*EncFS Password:*"
send "$pass\r"
expect eof

expect script output:

zz@zz-com:/media/truecrypt5/mmm$./e.sh 1
spawn encfs -v /media/truecrypt5/mmm/cr /media/truecrypt5/mmm/mn -o nonempty
10:25:11 (main.cpp:523) Root directory: /media/truecrypt5/mmm/cr/
10:25:11 (main.cpp:524) Fuse arguments: (daemon) (threaded) (keyCheck) encfs /media/truecrypt5/mmm/mn -o nonempty -s -o use_ino -o default_permissions 
10:25:11 (FileUtils.cpp:177) version = 20
10:25:11 (FileUtils.cpp:181) found new serialization format
10:25:11 (FileUtils.cpp:199) subVersion = 20100713
10:25:11 (Interface.cpp:165) checking if ssl/aes(3:0:2) implements ssl/aes(3:0:0)
10:25:11 (SSL_Cipher.cpp:370) allocated cipher ssl/aes, keySize 24, ivlength 16
10:25:11 (Interface.cpp:165) checking if ssl/aes(3:0:2) implements ssl/aes(3:0:0)
10:25:11 (SSL_Cipher.cpp:370) allocated cipher ssl/aes, keySize 24, ivlength 16
10:25:11 (FileUtils.cpp:1620) useStdin: 0
EncFS Password: 
10:25:11 (Interface.cpp:165) checking if ssl/aes(3:0:2) implements ssl/aes(3:0:0)
10:25:11 (SSL_Cipher.cpp:370) allocated cipher ssl/aes, keySize 24, ivlength 16
10:25:12 (FileUtils.cpp:1628) cipher key size = 44
10:25:12 (Interface.cpp:165) checking if nameio/block(3:0:1) implements nameio/block(3:0:0)

ls command:

zz@zz-com:/media/truecrypt5/mmm$sudo ls -la
[sudo] password for zz: 
ls: cannot access mn: Permission denied
total 24
drwx------  4 zz zz 4096 2012-08-31 14:40 .
drwx------ 10 zz zz 4096 1970-01-01 03:00 ..
drwx------  2 zz zz 4096 2012-08-30 18:56 cr
-rwx------  1 zz zz   73 2012-08-30 18:54 e2.sh
-rwx------  1 zz zz  178 2012-08-30 19:10 e.sh
d?????????  ? ?  ?     ?                ? mn
-rwx------  1 zz zz   40 2012-08-30 18:52 u.sh

I don't have access to {MNT_DIR}. Sodo user don't have access to. But command or shell scipt

#!/bin/sh
encfs -v  {CRIPT_DIR}  {MNT_DIR} -o nonempty

work correct.

OS: Ubuntu 11.10

What is wrong in my expect script?

share|improve this question
1  
I don't understand the question. What has sudo got to do with scripting the password for encfs? Do you mean that something is different depending on whether you use expect or not? What is different? –  Gilles Sep 3 '12 at 22:42
    
I mean that even sudo (root) user don't have access. –  zoloto Sep 6 '12 at 13:16
    
But does root have access when you don't use expect? And does the mounting work (i.e. do you have access) when you use expect? –  Gilles Sep 6 '12 at 13:23
    
Yes mounting work without expect./n encfs -v {CRIPT_DIR} {MNT_DIR} -o nonempty --- WORK –  zoloto Sep 6 '12 at 13:25
add comment

2 Answers

Using encfs in a expect script is different when executing a command because encfs forks a background process, but when the expect script exits, the encfs daemon becomes defunct. Sooner or later it'll get reclaimed by init.

So you may want to try using encfs -f to keep encfs running in the foreground and do not exit the script.

share|improve this answer
    
Thanks for answer. But with -f its don't work to. I have same problem in similar script in davfs. Its stack on stage of creating pid file in /var/run/mount.davfs/. –  zoloto Mar 14 '13 at 15:39
add comment

Nothing's wrong with your expect script. But it looks like you used your regular user to mount the encrypted directory, and then you are trying to see the mounted files with root using sudo. That will not work, and is the whole point of encfs.

In your example the directory cr is the storage used by encfs. The content of this is no big secret, it's encrypted data. You are mounting this data on mn, so that you can see its contents in a human-readable way, as files under mn.

Only the user that mounts cr will be able to read what's inside mn. Not even root can. If you want root to see the contents, then you should change your ./e.sh 1 in the example to sudo ./e.sh 1.

share|improve this answer
    
Regular user don't have access too. –  zoloto Sep 6 '12 at 13:14
    
The user that ran ./e.sh 1 above should be able to access it. –  janos Sep 6 '12 at 13:26
    
But haven't access –  zoloto Sep 6 '12 at 13:36
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.