Mount error: mount failed: File exists

You can use \x20 for space.

That is hex value for ASCII (and utf-8 encoded) space.

Or you can use the octal variant \040.

So that would be (in fstab):

UUID=01CD72098BB21B70 /media/tusharmakkar08/Local\x20Disk1
# or
UUID=01CD72098BB21B70 /media/tusharmakkar08/Local\040Disk1

If you are not to familiar with ASCII fun install ascii and:

ascii     # decimal and hex view
ascii -o  # octal view

Non the less I'd also recommend, like @TNW, changing the mount point to one without space. Generally makes things easier. You can also change the label though that might affect other things if you have something configured to recognize it as it is.

(I'm not sure why you're using the -o loop mount option, as the LVM snapshot device should be just as good a disk device as its original is.)

"File exists" is the standard English text for errno value 17, or EEXIST as it is named in #include <errno.h>.

That error result is not documented for the mount(2) system call, so a bit of source code reading is in order.

Linux kernel cross-referencer at elixir.bootlin.com can list all the locations where EEXIST is used in the kernel code. Since you're attempting to loop-mount a btrfs filesystem, the places that might be relevant are:

• drivers/block/loop.c, related to loop device management
• fs/btrfs/super.c, which would be used when mounting a btrfs filesystem.

In drivers/block/loop.c, the EEXIST error is generated if you're trying to allocate a particular loop device that is already in use (e.g. mount -o loop=/dev/loop3 ... and /dev/loop3 is already occupied). But that should not be the issue here, unless something is creating a race condition with your mount command.

The fs/btrfs/super.c actually has a btrfs-specific function for translating error codes into error messages. It translates EEXIST into Object already exists.

You are trying to mount what looks like a clone of a btrfs filesystem that is already mounted, so it actually makes sense: historically, this used to confuse btrfs, but it appears some protection has been (sensibly) added at some point.

Since this seems to be a LVM-level snapshot, as opposed to a snapshot made with btrfs's built-in snapshot functionality, you must treat the snapshot like a cloned filesystem if you wish to mount it while its origin filesystem is mounted: only the LVM will "know" that it's a snapshot, not an actual 1:1 clone. So, you'll need to change the metadata UUID of the snapshot/clone filesystem if you need to mount it on the same system as the original.

Warning: I don't have much experience on btrfs, so the below might be wrong or incomplete.

Since your kernel is newer than 5.0, you may have the option of using btrfstune -m /dev/mapper/matrix-snap--of--core to make the change. Otherwise you whould have to use btrfstune -u /dev/mapper/matrix-snap--of--core which would be slower as it needs to update all the filesystem metadata, not just the metadata_uuid field in the filesystem superblock.