Cannot mount truecrypt volume over network

[kartal]

Hi

I am trying to mount some /media/mount folders and I am failing badly with truecrypt ones. I do not know how to change the user permissions on the mounted drives. I tried with "sudo nautilus" but sudo itself could not change the permission on the drives.


I can mount some of the folders from the /media but not the truecrypt one. How is this done?


Any suggestions?

thanks

[Niva]

hmmm, found this thread which is attempting to address the issue I'm having. It's entirely too complicated. I wonder what is different about mounting network drives within linux than within windows because this stuff works in Windows without a hitch.

[cariboo]

Mounting shares is just as easy, as windows. The most common way is to use Samba which uses Windows protocols. As was cover in this thread, you can also use sshfs. Another way is to use nfs if you want to share directories between two or more linux based systems.

If you need help, we need more info.

[lmicu]

c|8^) Finally! Mounting Truecrypt Volumes across network, no more Permission denied: 8^) c|8^)

8^) Edit fuse.conf and add one line, my command on next line.

thomas@ubuntu:~$ sudo gedit /etc/fuse.conf

8^) Add the line below to /etc/fuse.conf on its own line exactly as shown:

user_allow_other



8^) I used sshfs with the syntax shown below (DON'T FORGET SUDO!!!!)

thomas@ubuntu:~$ sudo sshfs thomas@192.168.1.193:/ /home/thomas/mnt/tc -o allow_other


8^) Happy mounting!!!

This worked for me also, Thank you! Keep on Linux-ing!

[aston4]

can someone please explain where that path comes from in the post above?

I'm trying to get to a network share truecrypt volume via tomato installed on a router, & tomato assigns really weird names and paths to mounted disks.

I need to know which part of that command above is a path on the local machine, and which part of the path related to the remote volume.

[cariboo]

If you are refering to this line:

thomas@ubuntu:~$ sudo sshfs thomas@192.168.1.193:/ /home/thomas/mnt/tc -o allow_other

The location on the remote computer is this:

thomas@192.168.1.193:/

The path on the local computer is this:

/home/thomas/mnt/tc

For info on the sshfs switches, have a look at man sshfs

[aston4]

I'm still not getting the path right. I have a truecrypt file named "Volume" It is on a remote drive hanging off a Tomato router. Tomato assigns a name to this drive, the name is: "disc0_1 on 192.168.1.198" So if I want to get to that drive through Nautilus, or whatever, I go to: "/home/me/.gvfs/disc 0_1 on 192.168.1.198" When I try something like this: sudo sshfs Volume@192.168.3.198://"disc0_1 on 192.168.3.198"/ /home/me/mnt/tc -o allow_other or 29 other permutations of the above just always return this error: "read: Connection reset by peer" I wish it would just work like it does on the windows side of my machine... sigh. I've been trying to make this work for two months.

[Jack0239]

I have the same problem above and I have still no idea how to fix it. Is there anyone out there who can help us?

[doublemeat]

Actually the solution couldn't be simpler. You just need to add an option to the "mount" command:

uid={local username}

The complete command (in the case of CIFS/SMB) being:

sudo mount -t cifs //{host}/{share} {local mount point} -o user={remote username},uid={local username}

Note: Without specifying the password as an option (always a good idea to avoid plaintexting your passwords and/or in a way that bash history collects, IMO), this command would then prompt you for the remote password (after first prompting you for the sudo password of course).

All this does is mounts the share in a way that you (the user) can read and write to. Then, TrueCrypt has no problems accessing an encrypted volume stored on that share (assuming no other issues of course).

I don't know why this isn't widely discussed on the internets. I had to dig through the mount man page to discover this, after a fruitless internet search to this particular problem.

This is also not a hack or workaround. It's how mount was designed to work.

I should also point out that the previous solution discussed here is potentially dangerous, as it obviates the user-based security built-in to FUSE, and that TrueCrypt (and other FUSE modules such as EncFS) rely on: That is, by default only the current user can see the mounted volume! Modifying /etc/fuse.conf to add "user_allow_other", and specifying "allow_other" on the command line, overrides this behavior and allows any user to see your decrypted data.

If you've encrypted your data in the first place, there's a fairly good chance you wouldn't want this side effect!