我正在尝试使用以下命令在目录上设置 samba 上下文，我不确定此错误是什么，但我无法在目录上设置上下文。
semanage fcontext -a -t samba_share_t "/common(/.*)?"
抛出错误如下：
排除所需的完整路径：net:[4026532292]。
答案1
这个问题已经过去一年多了，但我在网上没有找到答案。让我们为下一个人解决这个问题。 :)
发生这些错误是因为某些东西在您的计算机上创建了网络命名空间。如果查看输出，mount您将看到 proc 文件系统类型安装在某个位置（可能在 /run 或 /var/run 下）并具有该编号。但是，如果您像restorecon（和semanage）那样查看/proc/mounts，您将看到相同的文件系统，其中“net：[xxx]”作为安装点。不幸的是，restorecon / semanage 不知道如何处理这个问题；他们只是看到一条不以 a 开头的路径/并发出错误。
为什么要这样做？如果您查看恢复源，您将看到 Restorecon 自动为未设置 seclabel 挂载选项的挂载点添加排除条目。语义管理大概也是如此。我认为 seclabel 选项应该由 SELinux 管理。它的作用是表明文件系统使用 xattrs 来存储 SELinux 属性。这就是这些文件系统被排除的原因：当文件系统不支持 SELinux 上下文时，尝试在文件上设置上下文是没有意义的。
伟大的。你如何解决它？系统selinux_restorecon()调用包含一个标志 - SELINUX_RESTORECON_IGNORE_MOUNTS - 它指示它不要进行该检查，但似乎没有办法告诉restorecon或semanage程序执行相同的操作。因此，一种选择是编写自己的 Restorecon 程序，该程序使系统调用带有忽略安装标签的标志。那是一种痛苦。 :) 我喜欢的一个更简单的选择是仅使用挂载上下文来隐藏那些您可能对遍历不感兴趣的挂载点。上下文导致了问题，那么为什么不也用上下文来解决它呢？
sudo unshare -m sh
umount $( mount | awk '$3~/netns/{print $3}' )
restorecon -rv /some/file
exit
用于unshare -m创建新的挂载命名空间并在该命名空间中运行 sh（在此处选择您最喜欢的 shell）。然后卸载有问题的文件系统。在我使用 Docker 执行此操作的情况下，文件系统全部包含netns（并且我没有带有该字符串的文件系统），因此我只需拉出匹配的挂载点并将其传递给 umount。其他人可能需要以不同的方式查找和卸载，但想法是相同的。因为unshare -m默认为私有挂载命名空间，所以卸载不会影响系统上的任何其他内容 - 它基本上隐藏了此进程的挂载。那时，我有一个 shell，其中这些文件系统不可见。因此，当restorecon在它从shell继承的命名空间中进行检查时/proc/self/mounts（技术上它是打开的/proc/mounts，但为了向后兼容，它是一个到支持挂载命名空间的系统的链接/proc/self/mounts），它可以毫无问题地运行。
如果您发现自己经常这样做，那么将 umount 和 Restorecon 放入 shell 脚本中并仅使用 Restorecon 运行它而不是启动 shell 可能是有意义的。
答案2
您看到的错误不是由在/common目录上应用 samba_share_t 上下文引起的。您仍然可以尝试restorecon -R /common，并检查 selinux 上下文确实已更改。我相信该错误源于之前的配置。