☰

使用相对路径指向不同挂载点上的文件时，符号链接不起作用

tag-icon • tag-icon linux linux-kernel
使用相对路径指向不同挂载点上的文件时，符号链接不起作用

在我的其中一台机器上，cd /var/lock尽管这/var/lock是到现有目录的符号链接，但仍然失败../run/lock。

经过进一步调查，我发现任何使用相对路径指向另一个挂载点的符号链接都会失败。这种情况只发生在这台特定的机器上。

例如，假设我有 3 个文件/var/foo、/data/foo和/run/foo，其中

  • /dev/vda镶嵌在/
  • /dev/vdb镶嵌在/data
  • tmpfs镶嵌在/run

在此处输入图片描述

[root@VM-16-197-centos ~]# cat /proc/self/mountinfo
18 40 0:18 / /sys rw,nosuid,nodev,noexec,relatime shared:6 - sysfs sysfs rw
19 40 0:3 / /proc rw,nosuid,nodev,noexec,relatime shared:5 - proc proc rw
20 40 0:5 / /dev rw,nosuid shared:2 - devtmpfs devtmpfs rw,size=32890360k,nr_inodes=8222590,mode=755
21 18 0:17 / /sys/kernel/security rw,nosuid,nodev,noexec,relatime shared:7 - securityfs securityfs rw
22 20 0:19 / /dev/shm rw,nosuid,nodev shared:3 - tmpfs tmpfs rw
23 20 0:12 / /dev/pts rw,nosuid,noexec,relatime shared:4 - devpts devpts rw,gid=5,mode=620,ptmxmode=000
24 40 0:20 / /run rw,nosuid,nodev shared:22 - tmpfs tmpfs rw,mode=755
25 18 0:21 / /sys/fs/cgroup ro,nosuid,nodev,noexec shared:8 - tmpfs tmpfs ro,mode=755
26 25 0:22 / /sys/fs/cgroup/systemd rw,nosuid,nodev,noexec,relatime shared:9 - cgroup cgroup rw,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd
27 18 0:23 / /sys/fs/pstore rw,nosuid,nodev,noexec,relatime shared:20 - pstore pstore rw
28 25 0:24 / /sys/fs/cgroup/hugetlb rw,nosuid,nodev,noexec,relatime shared:10 - cgroup cgroup rw,hugetlb
29 25 0:25 / /sys/fs/cgroup/cpuset rw,nosuid,nodev,noexec,relatime shared:11 - cgroup cgroup rw,cpuset
30 25 0:26 / /sys/fs/cgroup/blkio rw,nosuid,nodev,noexec,relatime shared:12 - cgroup cgroup rw,blkio
31 25 0:27 / /sys/fs/cgroup/net_cls,net_prio rw,nosuid,nodev,noexec,relatime shared:13 - cgroup cgroup rw,net_prio,net_cls
32 25 0:28 / /sys/fs/cgroup/freezer rw,nosuid,nodev,noexec,relatime shared:14 - cgroup cgroup rw,freezer
33 25 0:29 / /sys/fs/cgroup/cpu,cpuacct rw,nosuid,nodev,noexec,relatime shared:15 - cgroup cgroup rw,cpuacct,cpu
34 25 0:30 / /sys/fs/cgroup/perf_event rw,nosuid,nodev,noexec,relatime shared:16 - cgroup cgroup rw,perf_event
35 25 0:31 / /sys/fs/cgroup/memory rw,nosuid,nodev,noexec,relatime shared:17 - cgroup cgroup rw,memory
36 25 0:32 / /sys/fs/cgroup/devices rw,nosuid,nodev,noexec,relatime shared:18 - cgroup cgroup rw,devices
37 25 0:33 / /sys/fs/cgroup/pids rw,nosuid,nodev,noexec,relatime shared:19 - cgroup cgroup rw,pids
38 18 0:34 / /sys/kernel/config rw,relatime shared:21 - configfs configfs rw
40 0 253:1 / / rw,relatime shared:1 - ext4 /dev/vda1 rw,data=ordered
16 19 0:16 / /proc/sys/fs/binfmt_misc rw,relatime shared:23 - autofs systemd-1 rw,fd=33,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=11560
42 20 0:15 / /dev/mqueue rw,relatime shared:24 - mqueue mqueue rw
41 20 0:36 / /dev/hugepages rw,relatime shared:25 - hugetlbfs hugetlbfs rw
43 18 0:6 / /sys/kernel/debug rw,relatime shared:26 - debugfs debugfs rw
74 18 0:37 / /sys/fs/fuse/connections rw,relatime shared:55 - fusectl fusectl rw
76 24 0:38 / /run/user/0 rw,nosuid,nodev,relatime shared:57 - tmpfs tmpfs rw,size=6580380k,mode=700
78 16 0:39 / /proc/sys/fs/binfmt_misc rw,relatime shared:59 - binfmt_misc binfmt_misc rw
80 40 253:16 / / rw,relatime shared:61 - ext4 /dev/vdb rw,data=ordered
82 80 253:1 / / rw,relatime shared:63 - ext4 /dev/vda1 rw,data=ordered
84 40 253:16 / /data rw,relatime shared:65 - ext4 /dev/vdb rw,data=ordered

[root@VM-16-197-centos ~]# cat /etc/fstab

#
# /etc/fstab
# Created by anaconda on Thu Mar  7 06:38:37 2019
#
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
UUID=4b499d76-769a-40a0-93dc-4a31a59add28 /                       ext4    defaults        1 1
UUID=6906702c-65dd-4664-adf0-31ed67c92dab /                       ext4    defaults        1 1

[root@VM-16-197-centos ~]# readlink /proc/self/ns/{mnt,user} /proc/1/ns/{mnt,user}
mnt:[4026531840]
user:[4026531837]
mnt:[4026531840]
user:[4026531837]

我怀疑这是内核的一个错误。内核版本：3.10.0-1160.31.1.el7.x86_64 #1 SMP Thu Jun 10 13:32:12 UTC 2021。

SELinux 已禁用。

答案1

好的，根据/proc/self/mountinfo你的说法，这里有一些非常奇怪的坐骑关系。

此外，您/etc/fstab对由两个不同的 UUID 安装的根分区有两个引用，这看起来就像是根本原因。

以下mountinfo输出显示了坐骑之间的奇怪关系。

40 0 253:1 / / rw,relatime shared:1 - ext4 /dev/vda1 rw,data=ordered
80 40 253:16 / / rw,relatime shared:61 - ext4 /dev/vdb rw,data=ordered
82 80 253:1 / / rw,relatime shared:63 - ext4 /dev/vda1 rw,data=ordered
84 40 253:16 / /data rw,relatime shared:65 - ext4 /dev/vdb rw,data=ordered

第一个挂载（这很可能是启动时的原始挂载）位于第一行。它没有共享父级（第二个字段为 0）。随后，您已/dev/vdb在根路径之上挂载，其第二列父级为 40，这是第一个根挂载点的 ID，覆盖了您看到的 VFS，根为/dev/vdb-- 这可能是来自/etc/fstab和错误（其中一行fstab与无效的有关UUID，即UUID的/dev/vdb）。

由此，安装在顶部这再次挂载/dev/vda1。您可以看到第二行第二列中的挂载 ID（80）引用了第一列中的相同 ID。

第四行显示 (82) 的安装实际上是从原始 (40) 处的路径顶部/dev/vdb安装的- 这可能是预期的设置。这就是为什么您在自己的设置中监视它时会遇到问题的原因。/data//data

实际上，你所处的根分区是无效的，如果你从这个根目录向上移动一个目录，然后data再向下移动，相对于根目录，则没有挂载的/data子目录那 /小路。

您可以看到/data，如果您执行绝对查找（就像您正在做的那样），ls -ld因为解析相对路径的方式依赖于挂载点父/子关系，而绝对查找则不然。

要修复此问题，您需要这样做。

  • 通过确保转到UUID而/data不是/来修复 fstab 条目/dev/vdb。
  • 确定哪些进程正在使用新的根，
  • 停止这些进程。
  • 卸载坏的根。

但坦率地说，修复该问题fstab然后重新启动主机以纠正挂载状态可能更容易。

相关内容