1

Is there a way to make hard-links, from the client side, across two or more NFS mounts, if the shared NFS directories are hosted on a single backing filesystem? (Such that the server would have no problem with the inodes and hard-links if logged in locally or over ssh.)

I have a server providing multiple directories as NFSv4 shares. All of the shared directories are on one [ext4] file system. They are shared separately so the clients can mount them separately.

Within the directory tree of mounted share A or B individually, I can make a hard link of bar.file. But if I attempt to ln or cp -l between mount A and B I get an Invalid cross-device link error. Is there a way around this other than directly logging into the server?

I was thinking maybe a short script that reads the inode of the source and manually creates a file entry with the same inode in the destination directory, but that seems kind of hacky and I would need to research the needed components.

Or maybe some sort of union-mount solution?

Assume I have both regular user and root access to both systems.

13
  • 2
    You can't manually create a file entry to an arbitrary inode using the standard APIs. (That would allow accessing files contained in directories you have no access to.)
    – ilkkachu
    Apr 6, 2023 at 18:03
  • @ilkkachu root is always allowed access to all directories, and I can log into either system as root.
    – Max Power
    Apr 6, 2023 at 18:29
  • Why do you think that having the same inode on two different mounts would link the files in any way? It is quite common for two local file systems to have inodes in common and the files are not in any way related.
    – doneal24
    Apr 6, 2023 at 18:49
  • @doneal24 That isn't related to this issue. As stated in the question the NFS shares are all on one file system.
    – Max Power
    Apr 6, 2023 at 18:52
  • 1
    @MaxPower root is always allowed access to all directories Nope Apr 6, 2023 at 19:43

2 Answers 2

2

General observation

They are shared separately so the clients can mount them separately.

This reasoning makes little sense. If the parent directory was shared, clients could mount subdirectories separately anyway. One may want to share directories separately if there is (or if there may appear) something in the parent directory one does not want to share. This can be a valid reason, there may be other reasons. But…

Giving ability to mount separately is not a valid reason to share separately. NFSv4 gives the ability to clients regardless. /etc/exports on the server is an access control list rather than a list of separate shares clients must stick to. When using mount on a client, you are not limited to exact paths that are in /etc/exports on the server. As a client you can mount / of the server and still get access to all shares (and nothing more); or you can mount any subdirectory you are allowed to access.

Try mounting / of the server. Try mounting some (((…)sub-)sub-)subdirectory of some share. My point is you can.


Solution

Invalid cross-device link you got was because locally on the NFS client the paths you used were formally on separate "devices". The solution is to mount a hierarchy (directory tree) that includes all relevant shares, so it appears locally under one mountpoint (i.e. as a single "device").

On your NFS client mount the root directory (/) of the server; or the remote moutpoint of the remote filesystem in question; or some other common parent directory of the shares. A remote path you mount does not have to be explicitly exported on the server. Example:

sudo mount -t nfs 192.168.99.7:/remote/mountpoint /local/mountpoint

Under your local mounpoint you will see the content of the chosen remote directory limited to exported shares. E.g. if remote directories /remote/mountpoint/foo/A and /remote/mountpoint/bar/baz/B are exported and nothing in /remote/mountpoint/qux is exported (and even if neither / nor /remote/mountpoint is exported) then locally in /local/mountpoint you will see foo/ and bar/, but not qux/. You will be able to reach foo/A/ and bar/baz/B/.

Now, by working strictly under /local/mountpoint, you can ln locally between the directories A and B and if they are indeed on the same filesystem on the server and if you are permitted to write then the operation will succeed.

7
  • I guess the purpose is to handle cases where there are no common parent, like in mount address:/remote/A /mntA; mount address:/remote/B /mntB; ln /mntA/file /mntB/file... but of course, if there is a common parent, the solution is easy. Apr 6, 2023 at 19:59
  • @FrédéricLoyer In your example /remote is the common parent; when in doubt use /: mount address:/ /local/mountpoint && ln /local/mountpoint/remote/A/file /local/mountpoint/remote/B/file. Apr 6, 2023 at 20:05
  • If /remote/A and /remote/B are exported, but not /remote (nor / for obvious security reason), your proposition can't work. But sure, if /remote contains many exported directories, a new organisation could make safe to put these directories in a single one and export this directory. (Assuming the OP has an access to the server). Apr 6, 2023 at 20:23
  • @FrédéricLoyer My proposal can work. Try to mount / of some NFS server and you will be surprised. Apr 6, 2023 at 21:02
  • NFS is weird. I just wonder, does that depend on which NFS version one uses? On a quick look, I seem to get the impression the exports are separate in NFSv3, but parts of a single tree (as you describe above) in NFSv4.
    – ilkkachu
    Apr 7, 2023 at 20:21
1

A usual implementation of most file systems, including a NFS share, defines - like in an oriented object language - a set of operations (open, read...) you can do INSIDE the mounted filesystem. The NFS client implementation has no way to deal with operation with other filesystems. (From the client point of view, there are 2 file systems).

It may be theorically possible to have a dedicated client which mounts 2 NFS filesystems (sending NFS info), get 2 filehandles, then use them to link 2 files (sending NFS info too). But if it is not provided by your OS, it would be a lot of pain without a 100% chance of success. It could depend of the server implementation.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .