I have a TrueCrypt container on a Windows share that I'm trying to mount from Ubuntu. However, I consistently get a "Permission Denied" error.

I am using /home/kent/.gvfs/share on server/path/to/container as the path. I have tried mounting with the default options, mounting as read-only, and mounting to a specific directory. I get the same error regardless.

If I copy the container to my local Ubuntu machine then I can mount it and access it without issue. On a Windows desktop, I can mount it over the network without issue.

How can I mount this container from Ubuntu over my network?

  • Could you paste the actual commands that are resulting in the "Permission denied" error? – mgunes Oct 24 '10 at 17:39
  • @Murat: I'm just using the TrueCrypt UI - not sure what commands it's executing behind the scenes. Any way I can tell? – Kent Boogaart Oct 24 '10 at 18:31

.gvfs is a virtual mountpoint not owned by your login user (hence you don't have write-access to it). You will need to set up a mount point manually, e.g.

$ sudo mount -t cifs //server/share /mnt -o username=windowsuser,password=windowspassword

Once you have this you can mount the volume from there (in this example, /mnt) and it should work as expected.

  • Alas, I get: mount: wrong fs type, bad option, bad superblock on //server/share, missing codepage or helper program, or other error (for several filesystems (e.g. nfs, cifs) you might need a /sbin/mount.<type> helper program) In some cases useful info is found in syslog - try dmesg | tail or so. Log contains: smbfs: mount_data version 1919251317 is not supported. Any ideas? – Kent Boogaart Oct 24 '10 at 18:24
  • You have to fill in server and share with your values, e.g. // – Jonathon Oct 24 '10 at 19:07
  • 1
    I think you need to apt-get install smbfs – Jonathon Oct 24 '10 at 23:35
  • 1
    And the smbfs is now deprecated in favour of the fs keyword "cifs", so perhaps try changing the "fs" in your command to that. (But the apt-get comment is correct - it's still referred to as smbfs, annoyingly) – Scaine Oct 25 '10 at 10:38
  • 1
    Just tried this and it worked perfectly, both in mounting my Windows 2003 share AND then mapping a working truecrypt volume on that share : sudo mount -t cifs //server/share /home/scaine/Network/Share/ -o credentials=/home/scaine/password.txt. The password.txt is just a two line file, username=<userid> on one line and password=<your_password> on the second line. This can then be set such that only root can read it, providing a little bit of security. – Scaine Oct 25 '10 at 11:29

I posted this answer in the Ubuntu forum, but since I found the unanswered question here as well, I've more or less copied the same answer here...

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 (or EncFS or some other FUSE module) has no problem 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.

  • Very good to know and I just verified that this works for me. Thanks - I'll update my scripts accordingly. – Kent Boogaart Sep 7 '11 at 8:01

Try adding "user_allow_other" to /etc/fuse.conf, and mounting with the "allow_other" option.

  • Unfortunately, this didn't work - same problem. – Kent Boogaart Oct 24 '10 at 18:30

I would also try to mount it with smbfs, using :

mkdir /mnt/share
mount -t smbfs \\\\\\shared_folder /mnt/share -o username=your_username
  • And changing the IP address to match your server's IP, of course... – Nicolas Schirrer Oct 25 '10 at 13:33

Truecrypt is based on FUSE - which is a user-space filesystem. In short: only the user has permissive rights to access the mounted volume. In order to make SMB e. g. access the folder you have to avoid the daemon's capabilities of permission settings with a default mask on file-creation events:

force create mode 770

Make sure you export the volume on Windows accordingly: the mount point Truecrypt uses on Windows is also user-specific. That means your ActiveDirectory Daemon or whatever you chose, running as SYSTEM e. g., needs permissive rights in order to access the mount-point: perform a right-click on Windows, set the permissions, and remount the TC container. This should solve the issues from both sides ;)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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