Score:1

"Invalid cross-device link" hard for directories on the same filesystem

ck flag

I know hard links can't cross filesystems, but trying to link files via bind mounts that physically live on the same filesystem fails as well. I detailed things below to visualize it better, but the TLDR of my question is why is ln treating the mounted directories as though they live separately?

Basically, copying files into a share folder would be best-served with hardlinks so I'm not duplicating space:


mymedia/
├─ share/
│  ├─ pics/
│  │  ├─ pic2.tif
│  ├─ vids/
│  │  ├─ vid1.mov
├─ homevid/
│  ├─ vid1.mov
│  ├─ vid2.mov
│  ├─ vid3.mov
├─ homepic/
│  ├─ pic1.tif
│  ├─ pic2.tif
├─ training/




mymedia/share is on one drive (Media1), whereas homepic is on Media2 and homevid on Media3. The two folders in share are mounted from Media2/Media3. This is from fstab:

/dev/disk/by-uuid/UUID_1 /mnt/Media1 auto 0 0  
/dev/disk/by-uuid/UUID_2 /mnt/Media2 auto 0 0  
/dev/disk/by-uuid/UUID_3 /mnt/Media3 auto 0 0  
/mnt/Media1 /mnt/mymedia none bind 
/mnt/Media2/homepic /mnt/mymedia/homepic none bind
/mnt/Media2/share /mnt/mymedia/share/pics none bind
/mnt/Media3/homevid /mnt/mymedia/homevid none bind
/mnt/Media3/share /mnt/mymedia/share/vids none bind

I can create the link while using the "real" path, like so: ln /mnt/Media2/homepic/pic2.tif /mnt/Media2/share/, and see the new file in both directories; stat confirms the inode is the same for the files, as well as same device:

Path Device
/mnt/Media2/homepic 831h/2097d
/mnt/Media2/share 831h/2097d
/mnt/mymedia/homepic 831h/2097d
/mnt/mymedia/share/pics 831h/2097d
/mnt/mymedia/training 821h/2081d

Unfortunately, using the bind mounts would be way better for my workflow (this fails): ln /mnt/mymedia/homepic/pic1.tif /mnt/mymedia/share/pics/pic2.tif

What am I missing?

Hi-Angel avatar
es flag
You seem to have error in your fstab: you bind-mount both `Media2` and `Media3` to the same directory `/mnt/mymedia/share/pics`. If I understood correctly, these are different devices. Even if not, it doesn't make sense to have them bind-mounted to the same dir. And I guess that leads to the `ln` error you're seeing.
Bill avatar
ck flag
Thanks for pointing that out; that was a transcription error on my part and I edited the post. The `vids` and `pics` folders in `mymedia/share` each live on Media3/2. Maybe I still have an error though that I'm not catching, unless it has something to do with the parent (`mymedia/share`) living on Media1?
mook765 avatar
cn flag
`/dev/sda1 /mnt/Media1 /mnt/mymedia none bind` doesn't look like a valid fstab line. `/dev/sdb1 /mnt/Media2 none bind` is not a bind mount, your are mounting a device here, same for `/dev/sdc1 /mnt/Media3 none bind`. Device names like `/dev/sda1` should be avoided, use UUID or file-system labels to identify correct partitions.
Hi-Angel avatar
es flag
Can you please confirm if `df /mnt/mymedia/homepic/pic1.tif /mnt/mymedia/share/pics/` *(that is, `df` command over the parameters that make `ln` fail, except the second one is a dir, not a filename which wasn't created)* shows the same device for both arguments?
Bill avatar
ck flag
@Hi-Angel: it returns that they're on the same device: ```lang-bash $ df /mnt/mymedia/homepic/pic1.tif /mnt/mymedia/share/pics/ Filesystem 1K-blocks Used Available Use% Mounted on /dev/sdb1 13563485152 9514471848 3365377900 74% /mnt/mymedia/homepic/ /dev/sdb1 13563485152 9514471848 3365377900 74% /mnt/mymedia/share/pics/ ``` I guess I'm not sure whether to be thrilled or not! :) **EDIT:** My triple-backticks are getting garbled. Sorry!
Bill avatar
ck flag
@mook765 - You're right, it's not; that was another mistake of mine typing absent coffee. I updated by UUID and remounted. This should look more proper hopefully: ```lang-bash /dev/disk/by-uuid/UUID_1 /mnt/Media1 auto nosuid,nodev,nofail,x-gvfs-show,x-gvfs-name=Media1 0 0 /dev/disk/by-uuid/UUID_2 /mnt/Media2 auto nosuid,nodev,nofail,x-gvfs-show,x-gvfs-name=Media2 0 0 /mnt/Media1 /mnt/mymedia none bind /mnt/Media2/share /mnt/mymedia/share/pics none bind /mnt/Media2/homepic /mnt/mymedia/homepic none bind``` **EDIT:** My triple-backticks are getting garbled. Sorry!
mook765 avatar
cn flag
The fstab you provide here is still a mess, take a look at the third line: `/mnt/mymedia/share none bind ` is not a valid fstab line. Also now I don't see drive `Media1` mounted anywhere anymore.
Hi-Angel avatar
es flag
Apparently, [it is a deliberate feature](https://unix.stackexchange.com/a/380033/59928). The answer there refers to [this discussion](https://lists.archive.carbon60.com/linux/kernel/855705#855705), I don't fully understand the reasoning in the quoted email, but apparently it is a case of "never ever break userspace" kernel rule. Reflinks just happen to not work across bind-mounts on the same device, and apparently that feature became used in apps like Podman/Docker for containerization purposes *(it's just my theory from the comment)*, so one can't "undo" that behavior.
mook765 avatar
cn flag
https://stackoverflow.com/a/55387608
Bill avatar
ck flag
@mook765: The Media1 line wasn't rendering while on same line as the backticks; fixed it. if I'm reading your and @Hi-Angel's links correctly, Even though `/mnt/mymedia/share/pics` and `/mnt/Media2/share` live alongside each other, `ln` considers them different because the parent `/mnt/mymedia/share` lives on `/mnt/Media1`? Or could it (unlikely) be related to the directories living so close to `/mnt`?
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.