1

I keep sensitive data encrypted via luks, in container files. Those files are usually stored remotely (SMB, sshfs etc).

So my current workflow is as follows:

sudo mount $remoteshare /mnt
sudo cryptsetup open /mnt/encrypted.dsk decrypted
sudo mount /dev/mapper/decrypted local_mount_point

This works just fine, until I - for whatever reason - lose the connection. E.g. I move my laptop and lose WiFi or the machine falls asleep. Even when I have automount enabled (via Systemd for example), I get the response:

mount: /mnt: can't read superblock on /dev/mapper/decrypted.
   dmesg(1) may have more information after failed mount system call.

Researching this I found some reference that some work had been done on suspending those maps. But I couldn't find much more info than that.

Hence my question: is there a mechanism implemented that lets me restore those mounts without unmounting "decrypted", closing the /dev/mapper/decrypted device, then reopening and remounting?

Edit: Mostly I'm using sshfs, which is fuse-based. Experiments with smb3 returned in abysmal speed results.

/etc/fstab:

tomboy64@server:Media /home/tomboy64/mounts/Media   sshfs user,noauto,idmap=user,allow_other,x-systemd.automount,_netdev,uid=1007,gid=103,IdentityFile=/home/tomboy64/.ssh/id_ed25519,Compression=no,auto_cache,reconnect,ServerAliveInterval=5,ServerAliveCountMax=2,x-systemd.requires=network-online.target  0     0
Improve this question
4
  • Which remote filesystems exactly are you using for $remoteshare? Are they FUSE-based filesystems or in-kernel filesystems?
    – grawity_u1686
    Commented Aug 12, 2023 at 11:36
  • Added some info regarding the used filesystem.
    – tomboy64
    Commented Aug 12, 2023 at 20:23
  • Do you mount the filesystem directly (using sudo mount) or via systemd (using systemctl start)?
    – grawity_u1686
    Commented Aug 12, 2023 at 20:36
  • Please specify which mount. The decrypted partition I mount manually, as explained in the statement above. The underlying encrypted file is mounted via systemd automount, e.g. on access of the share. But the observed behavior is identical, regardless of how the underlying storage is mounted - manually or automatically. Both times the decrypted partition remains inaccessible.
    – tomboy64
    Commented Aug 26, 2023 at 18:17

0

Reset to default

You must log in to answer this question.

Browse other questions tagged .