maindavfs2 - Support: sr #106946, Problems with TrueCrypt containers...

 
 

sr #106946: Problems with TrueCrypt containers on WebDAV share

Submitter:  Holger Librenz <hlibrenz>
Submitted:  Fri 24 Jul 2009 12:31:09 PM UTC
   
 
Category:  None Priority:  5 - Normal
Severity:  3 - Normal Status:  None
Privacy:  Public Assigned to:  _71007
Open/Closed:  Closed Operating System:  GNU/Linux
* Mandatory Fields

Add a New Comment Rich Markup
   

Mon 27 Jul 2009 11:37:05 AM UTC, comment #5: 

Hi Werner.

Hmm, seems like I have to take a second look to another solution... As davfs copies the files it is - sadly - not the right solution for this special type of task. We will use such a "network attached storage" fs to prevent the need of local disk space :(

But, back to the origin topic:
I've tested your steps and have discovered, that new file creation with 'echo "test" > /media/webdav/test.txt' does not work. This seems to be a problem with the httpd / webdav module, provided by CentOS. In tests with a Tomcat driven WebDAV share I can mount the TrueCrypt and it seems to work quite fast. But the current test container is very, very small...

Thanks for your fast and direct answers!!

So long,
Holger

Holger Librenz <hlibrenz>
Fri 24 Jul 2009 07:33:42 PM UTC, comment #4: 

Hello Holger,

whether you can use davfs2 for this depends on
- how often TrueCrypt opens and closes the container
- how big the container is
- how fast your connection is
- and of course whether it works at all.
So if TrueCrypt only opens the container once when mounting and only closes it when unmounting, and you can wait for the changed container to be uploaded to the server, it might work.
You need enough local disk space to cache the complete container. davfs2 is definitely not suited to extend your local disk space.

But lets track down the problem. Here are some steps to take. If one step fails there is no use in trying the next.

1. Does the davfs2 file system work at all?
- you can read all the other files
- you can create new files (e.g. with 'echo', 'cat' or 'cp')
- these files appear on the server and can be accessed with other clients (e.g. a browser)
- no files are created in the lost+found directory of the davfs2 file system
- after unmounting and mounting again the files are still there and can be read
- does 'file' show reasonable values for the files (this is not a condition for step 2).

2. Can you copy the container with 'cp' from the davfs2 file system to a local disk?
- what does 'file' tell about this local copy
- does true crypt accept the local copy (if no we need step 3).

3. So you can read and copy the container from the davfs2  file system but TrueCrypt does not accept the container in davfs2 but accepts the one copied from davfs2 to alocal disk.
In this case there is something special about the file system calls issued by TrueCrypt. You should add option 'debug most' to your davfs2 config file, mount the davfs2 file system and try to mount the TrueCrypt file system.
There should be lots of messages from mount.davfs in one of your log files. Please send them to my private email adress together with the exact output of trucrypt. Please be sure to replace confidential information with 'XXX'.

Cheers
Werner


- <_71007>
Fri 24 Jul 2009 05:04:16 PM UTC, comment #3: 

Hi Werner.

Hmmm, so, if I understand you right, I have to look around for another "filesystem". I choosed WebDAV because a) currently only HTTPS is allowed for communication and b) it is a smart solution and does not have many dependencies ('k, and I can use re-use HTTPS ;) ).

But, back to topic: ls -l says that the files have r (if mounted ro) or rw (if mounted rw) rights. So the result of file is very curious! Have you seen such a behaviour before?

Best regards,
Holger

Holger Librenz <hlibrenz>
Fri 24 Jul 2009 03:17:28 PM UTC, comment #2: 

Hello Holger,

'file' says "no read permission". What does 'ls -l' say?

"right file meta data":
WebDAV isn't really a file system protocol. The only meta data all (?) WebDAV servers supply that can be matched into standard Unix file system meta data directly are:

WebDAV property "getcontentlength" -> file size (regular files only)
WebDAV property "getlastmodified" -> mtime
WebDAV property "resourcetype" -> directory or regular file

Additionally there are

WebDAV property "creationdate" -> initial value of ctime (it is not the same as ctime)
HTTP header "Content-Type" -> extended property "user.mime_type" (read-only)

Please note: davfs2 will always transfer the complete file (GET if modified on 'open', and PUT after writing and 'close'). So having a file on the WebDAV server which really is a container (and may be big) may cause a lot of traffic. It isn't what davfs2 was designed for. (Please see README)

Cheers
Werner

- <_71007>
Fri 24 Jul 2009 01:18:05 PM UTC, comment #1: 

Just a short update: I tried version 1.4.1 and the problem still exists....

Holger Librenz <hlibrenz>
Fri 24 Jul 2009 12:31:09 PM UTC, original submission:  

Hi.

Now I have a curious problem with DavFS in version 1.3.3 (Debian package davfs2 on Debian 5.0.2).

What I try: I will mount a WebDAV share via https on a Apache httpd  (version info: Apache/2.2.3 (CentOS)). This works, but if I try mounting a TrueCrypt container that is located on this share, TrueCrypt (Version 6.2a) does not accept it as a container!

Also 'file' returns curious information:
# file /media/webdav/hdb1.tc
/media/webdav/hdb1.tc: writable, regular file, no read permission

So, it just looks like davfs does not provide / cannot detect right file meta data. is there a known bug or can anybody just verify it?

The container seems to be Ok. The same file, just on a local device, can be used by TrueCrypt.

Hoping for help.

Best regards and thanks for the good work
Holger

Holger Librenz <hlibrenz>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by _71007 (Posted a comment)
  • -email is unavailable- added by hlibrenz (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2012-07-19 _71007 Open/ClosedOpen Closed
    2009-07-24 _71007 Assigned toNone _71007

    Back to the top

    Powered by Savane 3.13-aa77.
    Corresponding source code