使用相對路徑指向不同掛載點上的文件時，符號連結不起作用

在我的一台機器上，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 被禁用。

好的，根據/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。您可以看到第二 (80) 列中的掛載 ID 引用了第二行第一列中的相同 ID。

第四行顯示/dev/vdb（82）的安裝實際上是/data從原始路徑（40）的頂部安裝的/- 這可能是預期的設置。這就是為什麼/data當您在自己的設置中監視它時會遇到問題的原因。

實際上，您自己登陸的根分區是無效的，如果您從該根目錄上升一個相對目錄並再次向下進入相對於該根目錄的目錄，則該路徑中data沒有已安裝的子目錄。/data /

您可以查看/data是否像您正在執行的那樣執行絕對查找，ls -ld因為解析相對路徑的方式依賴於掛載點父/子關係，而絕對查找則不然。

要解決此問題，您將需要這樣做。

• 通過確保UUIDgo to/data而不是/for來修復 fstab 條目/dev/vdb。
• 確定哪些程序正在使用新根，
• 停止這些程序。
• 解除安裝壞根。

但坦率地說，修復它fstab然後重新啟動主機以更正安裝狀態可能更容易。

引用自：https://serverfault.com/questions/1105446