Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#5 Mounted target cannot be unmounted

v1.0 (example)
closed
RW Penney
None
5
2013-08-01
2013-03-26
Anonymous
No

Hi there,

in essence a target that *is* mounted is believed not to be mounted. Therefore, it cannot be unmounted. The target is a container file. That file is stored on an encrypted target, which is already mounted.

$ uname -a
Linux dfg-pc 3.2.0-39-generic #62-Ubuntu SMP Thu Feb 28 00:28:53 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

$ cryptmount --version
cryptmount-4.2.1

$ cryptmount secret
Enter password for target "secret":
e2fsck 1.42 (29-Nov-2011)
/dev/mapper/secret: clean, 6844/655360 files, 2373314/2621184 blocks

$ cryptmount -u secret
Target "secret" does not appear to be mounted

$ echo $?
1

$ cat /etc/cryptmount/cmtab

##################################################
# Physical disk

_DEFAULTS_ {
keyformat=luks
passwdretries=3
fstype=ext4
mountoptions=defaults,noatime,nodiratime,user,exec
}

data {
dev=/dev/disk/by-uuid/b36db545-6469-4498-bc04-39091560da8e
dir=/home/xxx/data
}

##################################################
# Containers

_DEFAULTS_ {
fstype=ext2
}

secret {
dev=/home/xxx/data/crypt/secret.luks
dir=/home/xxx/data/secret
}

In case you need further information, I'd by happy to assist. Just drop a comment.

Best regards,
Daniel

Discussion

  • RW Penney
    RW Penney
    2013-05-19

    Firstly, apologies for not seeing your bug report until now - my automatic email notifications were not working as hoped.

    I'm going to need some more details about your setup, because the scenario you describe sounds like exactly the sequence of operations that has been tested exhaustively, and should be an absolutely basic use case.

    Could you possibly try the 'cryptmount secret' operation again, and check the contents of the /dev/mapper/ directory, to check that it contains a file 'secret'. You could also check the output of 'df' to confirm that it lists your filesystem as being mounted. If either of those is not successful, and you're not getting any error messages from cryptmount itself, you could look at the tail end of /var/log/messages, where you should see some message from cryptmount reporting what actions it thinks it has performed.

    If you're able to mount your filesystem, but it's only the 'cryptmount -u secret' that fails, you may be able to use 'cryptmount --safetynet' as root to more forcibly unmount all filesystems managed by cryptmount.

    I'd certainly like to understand what circumstances triggered this issue, even if it turns out to have been something entirely transient. If you can let me know what type of Linux you have tried it on, how you installed it, how you setup your encrypted filesystem, and whether the problem is still recurring, that would be very helpful.

    Thanks,
    RW Penney

     
  • RW Penney
    RW Penney
    2013-05-19

    One possible issue is that the _DEFAULTS_ pseudo-target is not likely to work in the incremental fashion that you seem to be using. So, rather than specifying two '_DEFAULTS_', where the second is intended to override parameters in the first, you might like to try duplicating all the other settings from the first into the second.
    I'll add a comment to the cmtab.5 manual page to make that possible gotcha clearer.

     
  • RW Penney
    RW Penney
    2013-08-01

    This issue was eventually traced (via private correspondence with the original reporter) to a corrupted /etc/cryptmount/cmstatus file.
    Deleting that file seems to have fixed the problem.
    I plan to put further safeguards into cryptmount to reduce the risk of a similar issue recurring.

     
  • RW Penney
    RW Penney
    2013-08-01

    • status: open --> closed
    • assigned_to: RW Penney
    • Group: --> v1.0 (example)