While it's mounted, run
- Code: Select all
mount | grep '^\S\+ on /mnt/windows '
ls -ld /mnt/windows /mnt/windows/Windows /mnt/windows/Windows/explorer.exe
in a terminal and post the output. This is so we can see the various permissions on things regarding your mount to see what permission is causing the problem.
I suggest avoiding using CipherShed to call the final mount and use your system's mounting ability. I don't think it should be TrueCrypt's or CipherShed's responsibility to call the final mount. I think it should only be in charge of providing the block devices and let the user's environment take care of mounting. I think this is where the problem is originating. To "open" the TrueCrypt volume without mounting, run
- Code: Select all
sudo ciphershed -t /dev/sda1 --filesystem=none -m system --protect-hidden=no -k ""
This will create the block device (most likely in a place like /dev/mapper/ciphershed), that you should be able to mount with your file manager as if it was a flash drive or another hard drive. I'm not sure if the block device's location varies on different Linux systems, but I've seen them in /dev/mapper/ciphershed in Debian-based systems. I think they go wherever dmsetup usually puts them.
If you're not using a graphical environment, and you'd like to mount on command line, run something along the lines of
- Code: Select all
sudo mount /dev/mapper/ciphershedSOME_NUMBER /mnt/windows -t ntfs -o nodev,nosuid,noexec,fmask=177,dmask=077,uid=1000,gid=1000
This will mount it readable only to you, and doesn't allow execution of files
directly off of the volume.
Also, I took the time to test this with a freshly setup TrueCrypt encrypted Windows system and opened it with a Linux system (both in a VM), and I've found that my way,
and your way both work, so now I'm wondering if the ntfs driver on your system is intentionally mounting it as read-only due to corruption or a hard shutdown or something. You might want to check the last lines of 'dmesg' as soon as you mount to see if this is the case.