9

When I try to mount an lvm snapshot device, I get an error:

$ sudo mount -o loop /dev/mapper/matrix-snap--of--core /home/me/mountpoint
mount: /home/me/mountpoint: mount(2) system call failed: File exists.
  • What is the “File exists.” error trying to tell me?
  • What can I do to mount the lvm snapshot device?

The mount command has “always worked before”, though last time I checked was in October 2018. A similar error has been encountered in this three-year-old question. However, the error message is slightly different and it’s 2019 now …

This is my output for lsblk.

NAME                          MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda                             8:0    0 465.8G  0 disk  
└─sda1                          8:1    0 465.8G  0 part  
  └─core                      254:0    0 465.8G  0 crypt 
    ├─matrix-swapvolume       254:1    0     4G  0 lvm   [SWAP]
    └─matrix-core-real        254:3    0 461.8G  0 lvm   
      ├─matrix-core           254:2    0 461.8G  0 lvm   /
      └─matrix-snap--of--core 254:5    0 461.8G  0 lvm   
sdb                             8:16   1  59.5G  0 disk  
└─matrix-snap--of--core-cow   254:4    0  59.5G  0 lvm   
  └─matrix-snap--of--core     254:5    0 461.8G  0 lvm

I run Parabola Linux, my system is up-to-date. The logical volume /dev/matrix/core uses btrfs, which I suspect has something to do with the error. This is my output of uname -rvs.

Linux 5.2.5-gnu-1 #1 SMP PREEMPT Sun Aug 4 02:02:20 UTC 2019
k.stm
  • 689
  • 1
  • 11
  • 24

4 Answers4

15

(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.

telcoM
  • 87,318
  • 3
  • 112
  • 232
  • Tremendous answer! It worked perfectly. Thanks for the extra insights! I was wondering about the `-o loop`-part myself, that’s apparently the way I was doing it when I wrote the backup script ages ago – I’ve now removed the flag. Weird that I never had to do `btrfstune -m` before, maybe `lvm` didn’t clone the UUID before … Anyway, many, many thanks! – k.stm Aug 23 '19 at 19:28
  • 1
    A LVM snapshot does not care which filesystem is within the snapshotted LV: it just appears like a perfect clone of the LV as it existed at snapshot creation time, including cloning the UUID. But until fairly recently, there was nothing stopping you from mounting two cloned copies of the same `btrfs` filesystem at the same time, even though it might have caused bad things to happen unless the UUID was changed first. I guess the `btrfstune -m` option and the UUID check were both added recently, maybe in December 2018 or so, to make btrfs easy to use with LVM/SAN snapshots. – telcoM Aug 23 '19 at 20:26
  • Can you please clarify what is `matrix-snap--of--core`? – sequence Oct 12 '19 at 19:16
  • 1
    @sequence It's just the name of the device from the original question. Looks like they've named the LVM volume group `matrix` and the snapshot logical volume `snap-of-core`. LVM builds device names like `/dev/mapper/-`, and if either of those names contain dashes, they will be doubled to distinguish them from the dash that separates the VG name from the LV name. – telcoM Oct 12 '19 at 19:21
  • @telcoM I made a copy of a btrfs drive to a larger disk but for some reason I cannot boot from it and I could not even mount it until I read your post. I didn't have `/dev/mapper/matrix-snap--of--core`, but I did have `/dev/mapper/control`. Anyway, I used `btrfstune -m /dev/sdb3` which made the new drive mountable, but it didn't make it bootable still (for some reason I get a Ubuntu boot menu, which apparently doesn't work because I have openSUSE). Do you have any idea of why this is happening? I uesd Clonezilla to make an identical device to device copy. – sequence Oct 12 '19 at 19:37
  • @sequence Sounds like you don't have LVM, unlike in the original question. There are too many possible reasons why your cloned drive is not bootable: missing UEFI boot variables if using UEFI, old UUID in either GRUB configuration or in initramfs, just to name a few. You should post your own question instead of piggybacking on this one. – telcoM Oct 12 '19 at 20:13
  • I did it: https://unix.stackexchange.com/questions/546510/clonezilla-and-btrfs-grub-and-boot I'd appreciate your attention to this question. Actually LVM is in place in the source copy system. Do you know how one can copy to the disk bootsector in order to make it "distro-bootable"? – sequence Oct 12 '19 at 20:17
  • btrfs can sometimes be confused about device removals or reordering - in that case, it can be useful to run "btrfs scan -u" followed by "btrfs scan -d" to first forget all stale devices (that are no longer available) and then rescan all devices. – Remember Monica Apr 04 '20 at 19:21
  • 2
    I think you mean `btrfs device scan -u`, because `btrfs scan` does not exist. Anyway: I had the same issue, but this did not solve it. Had to reboot in order to remount the drive – Jelle De Loecker May 30 '20 at 20:55
  • Thanks for your awesome help. I was trying to mount a btrfs partition within an image file which I copied previously to SD card via dd. `btrfs device scan -u` did the trick. The whole mount command is `mount -o loop,offset=X file.img /mnt` where _X_ is `Start * Sector size` determined via `fdisk -l file.img` (see [post](https://www.linuxquestions.org/questions/linux-general-1/how-to-mount-img-file-882386/#post4365399)). – darkdragon Nov 10 '20 at 21:23
  • Explains (and resolves) an intermittent `system call failed: File exists.` error that's been driving me nuts for weeks. One of the best answers I've ever seen on SO. Thank you! – n8henrie Feb 01 '22 at 16:04
3

I've successfully mounted the BTRFS partition that had this problem after I changed the partition's UUID.

Michał Leon
  • 272
  • 2
  • 10
  • 1
    To change the partition's UUID; use, e.g., [`btrfstune -u /dev/sda1`](https://unix.stackexchange.com/a/246981/37153). – Geremia Mar 18 '23 at 22:01
0

The error occurs when the device is already mounted elsewhere. You need to umount first. Then you may create a new mount.

Karl Mistelberger
  • 1
  • 2
    Please have a look at the detailed explanation of what’s going on in the already accepted answer from half a year ago. – k.stm Feb 11 '20 at 11:16
0

This occurred to me because a Docker container was still trying to access the mount point on the host, which was also mounted in the container. It was an external USB drive that had disconnected, and the container blocked it from remounting. Stopping the container before remounting solved it.

Kasper Skytte Andersen
  • 101
  • 1
  • As it’s currently written, your answer is unclear. Please [edit] to add additional details that will help others understand how this addresses the question asked. You can find more information on how to write good answers [in the help center](/help/how-to-answer). – Community Feb 06 '23 at 16:48