Hi, I have a LUKS-encrypted file to hold my passwords and such. Most other distributions seem to be able to unmount it cleanly during shutdown, but openSUSE only shows the “stop job running for” message indefinitely long—the counter is given additional time every time it reaches the previous value. There’s no problem if and when I remember to unmount the LUKS file manually before shutdown.
What I need is a way to automatically unmount LUKS mount(s) during shutdown.
First I tried a /etc/rc.d/halt.local script:
#!/usr/bin/zsh
emulate -L zsh
local mountpoint owner
local -a mountpoints
mountpoints=($(mount | grep /local/private | cut -d " " -f 3))
for mountpoint in $mountpoints; do
owner=${mountpoint:t}
umount $mountpoint
cryptsetup luksClose ${owner}privatefs
fi
(In zsh because that’s what I know best.) This accomplished nothing. I have no idea if it was even executed but the “stop job running for” counter run just as before.
Next I tried to remodel a SystemD solution I found in the net for NFS mounts. I created a umount-luks.service file:
Is there some process running, that is keeping that file system busy?
How is the file system being mounted? Here, I have a partition that I mount as “/shared”. I have an entry for it in “/etc/crypttab” and an entry in “/etc/fstab”. So it is automatically mounted during boot (and I’m prompted for the key). I never see problems with this partition during shutdown.
I concur with @nrickert that it is a better idea to try and find out what goes wrong here, then, without knowing the root cause, going for a self made solution, that may run into the same problem.
Thus yes, provide information on how you let the system mount it as asked above.
Yeah, sorry, I actually first wrote that information down but then deleted it in order to be succinct
To use the encrypted file, I use a script to mount it in /local/private/$USER. The whole of the script is as follows.
#!/usr/bin/zsh
emulate -L zsh
if $EUID -ne 0 ]]; then
print -- ${0:t}: Cannot do that without sudo 1>&2
exit 1
fi
local d loopdev mountpoint privfile user
user=$(who am i | cut -d " " -f 1)
mountpoint=/local/private/$user
for d in /home /ext; do
-f $d/$user/.privatefs ]] && privfile=$d/$user/.privatefs && break
done
! -d $mountpoint ]] && mkdir -p $mountpoint
loopdev=$(losetup -f)
losetup $loopdev $privfile
if cryptsetup luksOpen $loopdev ${user}privatefs; then
mount -t ext4 /dev/mapper/${user}privatefs $mountpoint
else
print -- ${0:t}: Could not open the file 1>&2
fi
I agree the unmounting SHOULD happen automatically, and it does so in every other distro I’ve used.
The encrypted file contains only small text files, none of which is in use during logoff and shutdown—and even if they were, closing them should be a minor detail.
I missed that this was an encrypted file, rather than an encrypted partition.
I’ll make a wild guess. The file system (or partition) containing that file is being unmounted before the attempt to unmount the loop-mounted file. That would cause the lockup that you are experiencing. Maybe some checking of logs will help you find out whether my guess is right. And then perhaps a bug report will be in order.
This reminds me of when I had a problem in opensuse 13.2. I was using an NFS mount (with automount). And shutdown was stopping NetworkManager before it tried to unmount the NFS mount. That caused a similar lockup.
Sounds reasonable. I’ve already tried checking logs but I’m not sure (a) what I should look for, and (b) whether there should be anything. I mean, when the system gives the “stop job running for” message it’s only yet expecting something, not encountered an error. And since the only thing I can do (AFAIK) is to force reboot (using the SysRq keys) or shutdown (by pressing the power button long enough), I don’t think a message ever gets a chance to be recorded.
This reminds me of when I had a problem in opensuse 13.2. I was using an NFS mount (with automount). And shutdown was stopping NetworkManager before it tried to unmount the NFS mount. That caused a similar lockup.
Exactly. And this is what happens in most other distros if I forget to unmount the NFS shares on a laptop before I take it with me on a travel. This openSUSE handles well: when put to sleep, the laptop automatically disconnects the shares.
IMO your problem has little to do with LUKS, it’s simply how to automatically mount and unmount a loopback device.
So,
You should know that loopback devices are flexible and can be mounted/mounted many different ways, eg manually as you’ve done, the Desktop, GRUB, etc. and how you’d probably want to do it, by FSTAB.
Although a quick Google search returns numerous hits, IMO probably the best is the TLDP
But,
If I were asked, probably the simplest solution would be to create a LUKS encrypted partition using the Partitioner(YaST module) and write your file to the partition instead of on a loop device (unlees you have a reason to deploy a loop device instead).
When you Google for answers, be aware that there are a number of hits that are suited for SysInitV systems which describe something like what you tried to do (write an init script) which may not work in a systemd system nowadays.
I guess you are correct. It was just that I encountered this problem with LUKS and tended to identify it with that.
You should know that loopback devices are flexible and can be mounted/mounted many different ways, eg manually as you’ve done, the Desktop, GRUB, etc. and how you’d probably want to do it, by FSTAB.
This much I knew, but I thought I had reasons to do it my way. (Firstly, I wanted to mount the LUKS volume only when needed. Secondly, I had an idea to make it so that if I were to have multiple usernames on the same computer, each one could mount his own LUKS volume. And so on. Mostly bogus anyway, because I’m the sole user of my computers and only want ONE encrypted place to store my secrets.)
If I were asked, probably the simplest solution would be to create a LUKS encrypted partition using the Partitioner(YaST module) and write your file to the partition instead of on a loop device (unlees you have a reason to deploy a loop device instead).
Well, yes and no. I did have a partition once but it began to seem waste of space since I had so little to store on it. Currently, the encrypted file is 4 GB of size; I even tried 650 MB in order to back it up on a CD but that was too little. As I said, mostly it consists of website passwords and such.
Well, maybe that wasn’t the solution after all. The whole thing begins with creating a new squashfs filesystem—but I already have an ext4 filesystem in the file! And then, I didn’t see one example where the new filesystem would be read/write as needed.
I tried creating an /etc/fstab entry for the file, but of course that doesn’t work: even if the file when decrypted has an ext4 filesystem, the encrypted file doesn’t. So it’s a three-step losetup–cryptsetup–mount process (as evidenced for example by this).
In all honesty, you should set up an “ecryptfs” private directory. That will work far better for what you are trying to do.
Install “ecryptfs-utils”.
As root, run:
pam-config -a --ecryptfs
(that shouldn’t be needed, but I find that I have to do it. You only need to do that once).
Create your private directory with:
ecryptfs-setup-private
You run that as yourself. It will ask for your login password, which is used as the encryption key.
Before running that, perhaps run, as root:
modprobe ecryptfs
That also shouldn’t be needed, but I found that I needed it before setup. It is never needed again.
After that, you will have a directory named “Private” in your home directory. And everything in there is really encrypted, though you will see it in unencrypted form. The actual encrypted data will be in $HOME/.Private. That is mounted at $HOME/Private on login, using your login password as key. (If you use auto-login that won’t work and you will have to manually “ecryptfs-mount-private”). You do not need to pre-allocate space for a container.
The downside – some distros don’t support it. However, Ubuntu, Fedora and Debian do support it.
In my prior post, I tried to insert a hint that in the example code, “squashfs” should be replaced with whatever is appropriate for you.
For more about loopback devices and the file systems they support, I found that the standard documentation is hard to understand so I re-wrote that info in my Wiki page, maybe it’ll be helpful to you
As far as the ecrypt solution goes, I think I actually tried that too some time before but ended up using cryptsetup/LUKS for a reason I can’t recall any more. Might as well give that one a second chance too.
