Discussion:
Two questions about LUKS in a file container
(too old to reply)
r***@gmail.com
2020-09-12 16:20:01 UTC
Permalink
I'm thinking about putting my backup encrypted files in a LUKS filesystem within
a file instead of on a dedicated partition (for a few reasons).

I have two questions about that:

* if I don't have that LUKS filesystem "mounted" and open and I write to it,
I assume (or hope) that nothing will get written and I will get a warning or
error message of some sort?

* doesn't exactly apply to this situation, but, on the other hand, if my
"source" / original / non-backup LUKS system is in a file instead of on a
dedicated partition, and I use commands (like rsync or such) to copy the
unencrypted files not on the LUKS system, but I use options like the ones to
stay on the current filesystem (--one-file-system), I assume (or hope) that the
stuff in the encrypted partition will not get copied?
Hans
2020-09-12 16:50:01 UTC
Permalink
Am Samstag, 12. September 2020, 18:10:48 CEST schrieb ***@gmail.com:
Hi,
Post by r***@gmail.com
I'm thinking about putting my backup encrypted files in a LUKS filesystem
within a file instead of on a dedicated partition (for a few reasons).
* if I don't have that LUKS filesystem "mounted" and open and I write to
it, I assume (or hope) that nothing will get written and I will get a
warning or error message of some sort?
As far as I know, it is not possible, to mount an encrypted partition at all.
Post by r***@gmail.com
* doesn't exactly apply to this situation, but, on the other hand, if my
"source" / original / non-backup LUKS system is in a file instead of on a
dedicated partition, and I use commands (like rsync or such) to copy the
unencrypted files not on the LUKS system, but I use options like the ones to
stay on the current filesystem (--one-file-system), I assume (or hope) that
the stuff in the encrypted partition will not get copied?
Hmm, not quite sure, what you asked, but as far as I know, rsync does not
care, if the files or filesystems are encrypted or not. It just copies the
stuff to the target byte by byte. If there is something overwritten or not
readable / writable depends of your normal access rights.

Or am I wrong???

Best regards

Hans
Bob Weber
2020-09-12 19:10:01 UTC
Permalink
Post by r***@gmail.com
I'm thinking about putting my backup encrypted files in a LUKS filesystem within
a file instead of on a dedicated partition (for a few reasons).
* if I don't have that LUKS filesystem "mounted" and open and I write to it,
I assume (or hope) that nothing will get written and I will get a warning or
error message of some sort?
* doesn't exactly apply to this situation, but, on the other hand, if my
"source" / original / non-backup LUKS system is in a file instead of on a
dedicated partition, and I use commands (like rsync or such) to copy the
unencrypted files not on the LUKS system, but I use options like the ones to
stay on the current filesystem (--one-file-system), I assume (or hope) that the
stuff in the encrypted partition will not get copied?
I assume that you are referring to something like is described here:

https://willhaley.com/blog/encrypted-file-container-disk-image-in-linux/

The procedure described there creates a file encrypted.img that is a luks volume
that requires a filesystem (mkfs.ext4) and mount point to be used as a encrypted
storage.  If you want you can leave out --key-file mykey.keyfile and you will be
asked for a pass phrase.

Files can be copied with rsync to the mount point $HOME/Private/ and they will
be encrypted and not visible to the system after the umount and cryptsetup
luksClose commands.

In my experiment the file encrypted.img can be written to or truncated while it
is being used as a mounted encrypted volume but once you umount and luksClose
the file ALL DATA is lost!  So to be safe let the file encrypted.img belong to
root (with mode 600) and let a normal user write to the mounted volume at
$HOME/Private/ after the chown command is run for the user.  Once the file
encrypted.img is unmounted and closed out with luksClose it can be copied or
moved to other places like a flash drive like any other file.

Warning: If you forget to open and mount the file encrypted.img to
$HOME/Private/ and you copy files to $HOME/Private/ it will appear to work
correctly but they will not be encrypted!  If you don't move the files out of
$HOME/Private/ before you correct the mistake and mount encrypted.img you will
not see those files in $HOME/Private/ until you unmount encrypted.img.

Note:

By saying mount encrypted.img I mean the 2 commands: "cryptsetup luksOpen
encrypted.img myEncryptedVolume" and then "mount /dev/mapper/myEncryptedVolume
$HOME/Private/".

The unmount encrypted.img commands are "umount $HOME/Private/" and "cryptsetup
luksClose myEncryptedVolume".


I am not an expert on cryptsetup.  I have used these commands before but I was
curious to see if the system it protected encrypted.img while it was being
used.  I see that root can muck around with or delete encrypted.img making it
unusable so your only protections are just like other files .... backup!
--
*...Bob*
Andrei POPESCU
2020-09-16 09:00:03 UTC
Permalink
Post by Bob Weber
Warning: If you forget to open and mount the file encrypted.img to
$HOME/Private/ and you copy files to $HOME/Private/ it will appear to work
correctly but they will not be encrypted!  If you don't move the files out
of $HOME/Private/ before you correct the mistake and mount encrypted.img you
will not see those files in $HOME/Private/ until you unmount encrypted.img.
Regardless if encrypted or not, I think it is good practice to have all
mountpoints (NOT filesystems) owned by root and permission 0000.

Kind regards,
Andrei
--
http://wiki.debian.org/FAQsFromDebianUser
David Christensen
2020-09-16 20:00:02 UTC
Permalink
Post by Andrei POPESCU
Post by Bob Weber
Warning: If you forget to open and mount the file encrypted.img to
$HOME/Private/ and you copy files to $HOME/Private/ it will appear to work
correctly but they will not be encrypted!  If you don't move the files out
of $HOME/Private/ before you correct the mistake and mount encrypted.img you
will not see those files in $HOME/Private/ until you unmount encrypted.img.
Regardless if encrypted or not, I think it is good practice to have all
mountpoints (NOT filesystems) owned by root and permission 0000.
That's an interesting suggestion. /f1 is a mount point on my
workstation for the root filesystem on one of my servers:

2020-09-16 12:34:14 ***@tinkywinky ~
# grep f1 /etc/fstab
f1:/ /f1 fuse.sshfs ro,noauto 0 0


It is not mounted:

2020-09-16 12:34:20 ***@tinkywinky ~
# mount | grep f1


The permissions on the mount point are default, as set by mkdir(1):

2020-09-16 12:35:42 ***@tinkywinky ~
# ll -d /f1
drwxr-xr-x 2 root root 4096 2020-09-16 12:33:41 /f1/


If I change the mode of the mount point to 0000:

2020-09-16 12:51:28 ***@tinkywinky ~
# chmod 0000 /f1

2020-09-16 12:53:08 ***@tinkywinky ~
# ls -la /f1
total 8
d--------- 2 root root 4096 Sep 16 12:53 .
drwxr-xr-x 26 root root 4096 Aug 30 13:39 ..


Root can still create files inside the mount point:

2020-09-16 12:53:09 ***@tinkywinky ~
# echo 'hello, world!' > /f1/hello

2020-09-16 12:53:41 ***@tinkywinky ~
# ls -la /f1
total 12
d--------- 2 root root 4096 Sep 16 12:53 .
drwxr-xr-x 26 root root 4096 Aug 30 13:39 ..
-rw-r--r-- 1 root root 14 Sep 16 12:53 hello

2020-09-16 12:53:44 ***@tinkywinky ~
# cat /f1/hello
hello, world!


Is there some advantage other than making a long listing visually
distinctive when the mount point is not in use?


David
David Wright
2020-09-16 21:40:02 UTC
Permalink
Post by David Christensen
Post by Andrei POPESCU
Post by Bob Weber
Warning: If you forget to open and mount the file encrypted.img to
$HOME/Private/ and you copy files to $HOME/Private/ it will appear to work
correctly but they will not be encrypted!  If you don't move the files out
of $HOME/Private/ before you correct the mistake and mount encrypted.img you
will not see those files in $HOME/Private/ until you unmount encrypted.img.
Regardless if encrypted or not, I think it is good practice to have all
mountpoints (NOT filesystems) owned by root and permission 0000.
That's an interesting suggestion. /f1 is a mount point on my
# grep f1 /etc/fstab
f1:/ /f1 fuse.sshfs ro,noauto 0 0
# mount | grep f1
# ll -d /f1
drwxr-xr-x 2 root root 4096 2020-09-16 12:33:41 /f1/
# chmod 0000 /f1
# ls -la /f1
total 8
d--------- 2 root root 4096 Sep 16 12:53 .
drwxr-xr-x 26 root root 4096 Aug 30 13:39 ..
# echo 'hello, world!' > /f1/hello
# ls -la /f1
total 12
d--------- 2 root root 4096 Sep 16 12:53 .
drwxr-xr-x 26 root root 4096 Aug 30 13:39 ..
-rw-r--r-- 1 root root 14 Sep 16 12:53 hello
# cat /f1/hello
hello, world!
Is there some advantage other than making a long listing visually
distinctive when the mount point is not in use?
Yes. As explained earlier in the thread, it prevents user OP from
accidentally scribbling in the unused mountpoint. You've confirmed
that unix file permissions don't affect root.

Another side-effect is that you can't enter the mountpoint directory
in, say, mc, which avoids your thinking that the intended filesystem
(were it actually mounted) is itself empty.

But—I see that your own intended filesystem for f1 is fuse.sshfs.
Can you, as a user, mount this filesystem now? I'd be interested
to know how, if you can, because I'm just now thinking about enhancing
my udev rule to chown a mount (in favour of me) if the fstab entry
is a fuse one (eg ntfs and exfat).

Cheers,
David.
David Christensen
2020-09-17 20:40:03 UTC
Permalink
Post by David Wright
Post by David Christensen
Is there some advantage other than making a long listing visually
distinctive when the mount point is not in use?
Yes. As explained earlier in the thread, it prevents user OP from
accidentally scribbling in the unused mountpoint.
The default permissions 0755 already do that:

2020-09-17 13:21:22 ***@tinkywinky ~
$ touch /f1/foo
touch: cannot touch '/f1/foo': Permission denied
Post by David Wright
Another side-effect is that you can't enter the mountpoint directory
in, say, mc, which avoids your thinking that the intended filesystem
(were it actually mounted) is itself empty.
2020-09-17 13:23:59 ***@tinkywinky ~
$ ssh ***@localhost
Linux tinkywinky 4.9.0-13-amd64 #1 SMP Debian 4.9.228-1 (2020-07-05) x86_64
Last login: Wed Sep 16 12:31:13 2020 from ::1

2020-09-17 13:24:03 ***@tinkywinky ~
# chmod 0000 /f1

2020-09-17 13:24:08 ***@tinkywinky ~
# q
logout
Connection to localhost closed.

2020-09-17 13:24:17 ***@tinkywinky ~
$ cd /f1
bash: cd: /f1: Permission denied


Confirmed -- changing mode to 0000 prevents non-root users from changing
into that directory.
Post by David Wright
But—I see that your own intended filesystem for f1 is fuse.sshfs.
Can you, as a user, mount this filesystem now? I'd be interested
to know how, if you can, because I'm just now thinking about enhancing
my udev rule to chown a mount (in favour of me) if the fstab entry
is a fuse one (eg ntfs and exfat).
I have always mounted /f1 as root. Trying it as non-root:

2020-09-17 13:24:24 ***@tinkywinky ~
$ mount /f1
mount: only root can mount f1:/ on /f1


David
David Wright
2020-09-19 15:00:02 UTC
Permalink
Post by David Christensen
Post by David Wright
Post by David Christensen
Is there some advantage other than making a long listing visually
distinctive when the mount point is not in use?
Yes. As explained earlier in the thread, it prevents user OP from
accidentally scribbling in the unused mountpoint.
$ touch /f1/foo
touch: cannot touch '/f1/foo': Permission denied
Only because root created the mount point, as root would have to do
for a mount point in /.

The blog example uses $HOME/Private/ which would, with a typical
user's umask, be writeable by the user.
Post by David Christensen
Post by David Wright
Another side-effect is that you can't enter the mountpoint directory
in, say, mc, which avoids your thinking that the intended filesystem
(were it actually mounted) is itself empty.
Linux tinkywinky 4.9.0-13-amd64 #1 SMP Debian 4.9.228-1 (2020-07-05) x86_64
Last login: Wed Sep 16 12:31:13 2020 from ::1
# chmod 0000 /f1
# q
logout
Connection to localhost closed.
$ cd /f1
bash: cd: /f1: Permission denied
Confirmed -- changing mode to 0000 prevents non-root users from
changing into that directory.
Post by David Wright
But—I see that your own intended filesystem for f1 is fuse.sshfs.
Can you, as a user, mount this filesystem now? I'd be interested
to know how, if you can, because I'm just now thinking about enhancing
my udev rule to chown a mount (in favour of me) if the fstab entry
is a fuse one (eg ntfs and exfat).
$ mount /f1
mount: only root can mount f1:/ on /f1
Oh, OK. I was hoping you might have cracked how to mount a fuse
filesystem as a user, as described in:

What is FUSE?
~~~~~~~~~~~~~

FUSE is a userspace filesystem framework. […]

One of the most important features of FUSE is allowing secure,
non-privileged mounts. This opens up new possibilities for the use of
filesystems. A good example is sshfs: a secure network filesystem
using the sftp protocol.

https://www.kernel.org/doc/Documentation/filesystems/fuse.txt

But with my experiments (on exFAT), I couldn't get past what looks
like #916987:

$ mount /media/cruzer4g/
FUSE exfat 1.3.0
fusermount: unknown option 'user=david'
$

That was after adding user_allow_other to /etc/fuse.conf (which
I didn't want) to get past:

$ mount /media/cruzer4g/
FUSE exfat 1.3.0
fusermount: option allow_other only allowed if 'user_allow_other' is set in /etc/fuse.conf
$

… and after being taking ownership of both mount point and device file.

So I'm mounting with sudo, and appending ,umask=077,uid=1000,gid=1000
to the fstab entry to gain user access to the filesystem.

Do you know if fuse exFAT is a stopgap, and support in the kernel is
eventually coming, or was a fuse implementation necessarily chosen
to support exFAT on account of some particular problem. It seems odd
that pmount, for example, doesn't support exFAT (which would seem
a prime candidate).

The fuse documentation is so fragmentary, scattered and sparse that
I haven't really got a good feel for what is is or how it works.
I'm always thinking that I've missed some option or other that allows
it to work as I expected it to.

Cheers,
David.
David Christensen
2020-09-19 21:10:02 UTC
Permalink
Post by David Wright
Post by David Christensen
Post by David Wright
Post by David Christensen
Is there some advantage other than making a long listing visually
distinctive when the mount point is not in use?
Yes. As explained earlier in the thread, it prevents user OP from
accidentally scribbling in the unused mountpoint.
$ touch /f1/foo
touch: cannot touch '/f1/foo': Permission denied
Only because root created the mount point, as root would have to do
for a mount point in /.
The blog example uses $HOME/Private/ which would, with a typical
user's umask, be writeable by the user.
2020-09-19 13:20:00 ***@tinkywinky ~
$ cat /etc/debian_version ; uname -a
9.13
Linux tinkywinky 4.9.0-13-amd64 #1 SMP Debian 4.9.228-1 (2020-07-05)
x86_64 GNU/Linux

2020-09-19 13:24:20 ***@tinkywinky ~
$ mkdir mountpoint

2020-09-19 13:24:24 ***@tinkywinky ~
$ touch mountpoint/foo

2020-09-19 13:24:28 ***@tinkywinky ~
$ chmod 0000 mountpoint

2020-09-19 13:24:37 ***@tinkywinky ~
$ touch mountpoint/bar
touch: cannot touch 'mountpoint/bar': Permission denied


Okay. I can see how that might alert me if I attempt to write to a
mountpoint that is not active.
Post by David Wright
... I was hoping you might have cracked how to mount a fuse
What is FUSE?
~~~~~~~~~~~~~
FUSE is a userspace filesystem framework. […]
One of the most important features of FUSE is allowing secure,
non-privileged mounts. This opens up new possibilities for the use of
filesystems. A good example is sshfs: a secure network filesystem
using the sftp protocol.
https://www.kernel.org/doc/Documentation/filesystems/fuse.txt
But with my experiments (on exFAT), I couldn't get past what looks
$ mount /media/cruzer4g/
FUSE exfat 1.3.0
fusermount: unknown option 'user=david'
$
That was after adding user_allow_other to /etc/fuse.conf (which
$ mount /media/cruzer4g/
FUSE exfat 1.3.0
fusermount: option allow_other only allowed if 'user_allow_other' is set in /etc/fuse.conf
$
… and after being taking ownership of both mount point and device file.
So I'm mounting with sudo, and appending ,umask=077,uid=1000,gid=1000
to the fstab entry to gain user access to the filesystem.
Do you know if fuse exFAT is a stopgap, and support in the kernel is
eventually coming, or was a fuse implementation necessarily chosen
to support exFAT on account of some particular problem. It seems odd
that pmount, for example, doesn't support exFAT (which would seem
a prime candidate).
The fuse documentation is so fragmentary, scattered and sparse that
I haven't really got a good feel for what is is or how it works.
I'm always thinking that I've missed some option or other that allows
it to work as I expected it to.
2020-09-19 14:04:40 ***@tinkywinky ~
$ apt-cache search fuse | grep FAT
exfat-fuse - read and write exFAT driver for FUSE
fusefat - File System in User Space - Module for FAT
umview-mod-umfusefat - View-OS in user space - FAT module for UMFUSE


Have you tried exfat-fuse or fusefat?


David
Andrei POPESCU
2020-09-21 06:00:02 UTC
Permalink
Post by David Wright
Do you know if fuse exFAT is a stopgap, and support in the kernel is
eventually coming, or was a fuse implementation necessarily chosen
to support exFAT on account of some particular problem. It seems odd
that pmount, for example, doesn't support exFAT (which would seem
a prime candidate).
https://fossbytes.com/linux-5-7-microsofts-exfat-driver-code/

Kind regards,
Andrei
--
http://wiki.debian.org/FAQsFromDebianUser
David Wright
2020-09-21 14:30:02 UTC
Permalink
Post by David Christensen
Post by David Wright
The fuse documentation is so fragmentary, scattered and sparse that
I haven't really got a good feel for what is is or how it works.
I'm always thinking that I've missed some option or other that allows
it to work as I expected it to.
$ apt-cache search fuse | grep FAT
exfat-fuse - read and write exFAT driver for FUSE
fusefat - File System in User Space - Module for FAT
umview-mod-umfusefat - View-OS in user space - FAT module for UMFUSE
Have you tried exfat-fuse or fusefat?
I think exfat-fuse is what I am using, and fusefat appears to consider
rw as experimental, from what I have read.
Post by David Christensen
Post by David Wright
Do you know if fuse exFAT is a stopgap, and support in the kernel is
eventually coming, or was a fuse implementation necessarily chosen
to support exFAT on account of some particular problem. It seems odd
that pmount, for example, doesn't support exFAT (which would seem
a prime candidate).
https://fossbytes.com/linux-5-7-microsofts-exfat-driver-code/
Thanks. In which case, I think I'll pause on doing anything about
exFAT in the immediate future. Currently I max out at 32GB on SD
cards; anything larger is either USB or spinning rust. (Also, as
I write this, my SO is getting ubuntu installed as a VM on her
Windows machine.)

Cheers,
David.

Charles Curley
2020-09-12 19:40:01 UTC
Permalink
On Sat, 12 Sep 2020 12:10:48 -0400
Post by r***@gmail.com
I'm thinking about putting my backup encrypted files in a LUKS
filesystem within a file instead of on a dedicated partition (for a
few reasons).
Why do you want a file system inside a file? The only reason I can
think of to do that is to emulate the file system of another computer,
e.g. a virtual machine. But in that case, I wonder why you want to feed
your backups to a VM.
Post by r***@gmail.com
* if I don't have that LUKS filesystem "mounted" and open and I
write to it, I assume (or hope) that nothing will get written and I
will get a warning or error message of some sort?
It depends.

If you are create a new file to write to, and it would be in the root
director of the partition (e.g. /mnt/foo), then Linux will cheerfully
create the file and write to it in the mount point directory, on that
file system.

If you try to open an existing file, it will fail.

Otherwise, you will get an error because the directory structure won't
be there.

Whether you get an error message or not depends on which program you
use.
Post by r***@gmail.com
* doesn't exactly apply to this situation, but, on the other hand,
if my "source" / original / non-backup LUKS system is in a file
instead of on a dedicated partition, and I use commands (like rsync
or such) to copy the unencrypted files not on the LUKS system, but I
use options like the ones to stay on the current filesystem
(--one-file-system), I assume (or hope) that the stuff in the
encrypted partition will not get copied?
Huh?

Figure out which program you are going to use, and read the man page.



You appear to specialize in coming up with oddball solutions to
problems and then asking us how to implement your solution.

Instead, how about describing your problem and asking how we would
suggest you solve it? Plenty of us have already dealt with the sorts of
problems you seem to have, and solved them.

As far as getting backups onto encrypted partitions, say for off-site
storage, goes: I have a solution that works for me. Start with
http://charlescurley.com/blog/posts/2019/Nov/02/backups-on-linux/
--
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/
David Christensen
2020-09-12 23:00:02 UTC
Permalink
Post by Charles Curley
On Sat, 12 Sep 2020 12:10:48 -0400
Post by r***@gmail.com
I'm thinking about putting my backup encrypted files in a LUKS
filesystem within a file instead of on a dedicated partition (for a
few reasons).
Why do you want a file system inside a file? The only reason I can
think of to do that is to emulate the file system of another computer,
e.g. a virtual machine.
There are many use-cases. In the context of rsync(1) backups, each file
contains one backup filesystem. If you have seven such files, you can
rotate them daily and one complete backup for each day of the week. If
you set the backup image file permissions correctly, you can easily view
and/or move those files using standard tools. But, one challenge is
finding the "right" file size. Some people use LVM inside the files to
provide additional flexibility.


David
David Christensen
2020-09-12 22:20:01 UTC
Permalink
Post by r***@gmail.com
I'm thinking about putting my backup encrypted files in a LUKS filesystem within
a file instead of on a dedicated partition (for a few reasons).
* if I don't have that LUKS filesystem "mounted" and open and I write to it,
I assume (or hope) that nothing will get written and I will get a warning or
error message of some sort?
AIUI "LUKS volumes" are "opened" and "closed", and "filesystems" are
"mounted" and "unmounted".


If you issue a command that writes into a file containing a LUKS volume,
open or closed, you will corrupt things:

https://lists.debian.org/debian-user/2020/08/msg00690.html
Post by r***@gmail.com
* doesn't exactly apply to this situation, but, on the other hand, if my
"source" / original / non-backup LUKS system is in a file instead of on a
dedicated partition, and I use commands (like rsync or such) to copy the
unencrypted files not on the LUKS system, but I use options like the ones to
stay on the current filesystem (--one-file-system), I assume (or hope) that the
stuff in the encrypted partition will not get copied?
When using the rsync(1) with the "--recursive" option, adding the
"--one-file-system" option prevents rsync(1) from recursing into mount
points under SRC.


For example, my workstations include the directory
"/home/dpchrist/samba/dpchrist". It is the mount point for a share on
the server "samba". The server data is backed up by one job.
Workstation home directories are backed up by another job. The home
directory backup jobs use the "--one-file-system" option, so that the
server data is not backed up multiple times.


I would avoid issuing one rsync(1) command that includes both a LUKS/
filesystem image file and its mount point as SRC arguments or under SRC
arguments. It might "work", but the results could be surprising.


David
r***@gmail.com
2020-09-13 00:10:01 UTC
Permalink
Thank you!

(Nothing new below this line.)
Post by r***@gmail.com
I'm thinking about putting my backup encrypted files in a LUKS filesystem
within a file instead of on a dedicated partition (for a few reasons).
David Wright
2020-09-13 15:20:01 UTC
Permalink
Post by r***@gmail.com
I'm thinking about putting my backup encrypted files in a LUKS filesystem within
a file instead of on a dedicated partition (for a few reasons).
* if I don't have that LUKS filesystem "mounted" and open and I write to it,
I assume (or hope) that nothing will get written and I will get a warning or
error message of some sort?
Create a permanent mount point with the permissions set to ugo=
ie nothing.

If you're afraid that root will read or write to it,
then instead use a script like the following:

. unlock the LUKS
. mkdir the mount point
. mount the filesystem

When finished with the container, another script:

. umount the filesystem
. rmdir the mount point
. lock the LUKS

To have the mount point cleaned up when you close down (forgetting to run
the latter script), make the mount point under /tmp.
Post by r***@gmail.com
* doesn't exactly apply to this situation, but, on the other hand, if my
"source" / original / non-backup LUKS system is in a file instead of on a
dedicated partition, and I use commands (like rsync or such) to copy the
unencrypted files not on the LUKS system, but I use options like the ones to
stay on the current filesystem (--one-file-system), I assume (or hope) that the
stuff in the encrypted partition will not get copied?
I assume that --one-file-system would notice that the encrypted
filesystem is read from /dev/dm-*, whereas the container file is
being read from /dev/sd*, and would avoid using the former.

Cheers,
David.
David
2020-09-13 15:30:01 UTC
Permalink
Post by David Wright
Create a permanent mount point with the permissions set to ugo=
ie nothing.
I do this for all my permanent mountpoints and then set the
immutable bit on them.

This prevents accidental writes and the bonus is that
ls -l /mnt
shows clearly which of its subdirectories are in use as
mountpoints, (assuming that what is mounted has
typical nonzero permissions). Handy when there's a lot
of them.
Loading...