![使用相对路径指向不同挂载点上的文件时,符号链接不起作用](https://linux22.com/image/778635/%E4%BD%BF%E7%94%A8%E7%9B%B8%E5%AF%B9%E8%B7%AF%E5%BE%84%E6%8C%87%E5%90%91%E4%B8%8D%E5%90%8C%E6%8C%82%E8%BD%BD%E7%82%B9%E4%B8%8A%E7%9A%84%E6%96%87%E4%BB%B6%E6%97%B6%EF%BC%8C%E7%AC%A6%E5%8F%B7%E9%93%BE%E6%8E%A5%E4%B8%8D%E8%B5%B7%E4%BD%9C%E7%94%A8.png)
在我的其中一台机器上,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
然后重新启动主机以纠正挂载状态可能更容易。