我已经看过这两个了：
但是，我的问题似乎有所不同。
我已经构建了一个用于调用Linux CLI工具的扩展库。它围绕proc_open，它的家庭和POSIX。
我正在使用它来成功执行 all （直到我点击此mount / umount错误）CLI工具。
现在，我正在构建一个RAID设置例程，涉及partprobe，parted - rm ， mklabel ， mkpart ，mdadm - 停止，零超级块，创建，dd，{{1}最终mkfs / mount。
实际上有两个优雅的例程，一个用于组装RAID，另一个用于反汇编。
正如标题所说，问题依赖于umount和mount。上面列出的其他工具及其命令执行成功。
Arch Linux - Linux stone 3.11.6-1-ARCH＃1 SMP PREEMPT Fri Oct 18 23:22:36 CEST 2013 x86_64 GNU / Linux。
Arch与umount一起运行 - 可能会以某种方式影响安装。
运行mod_php（最新）的Apache Web服务器（最新版）。 Apache以systemd运行。
http:http位于http组，wheel是sudoers - wheels。
请不要启动 %wheel ALL=(ALL) NOPASSWD: ALL进行完全根功能讨论 - 该单元是NAS，它运行的是自定义WebOS，它仅适用于Intranet。即使有黑客攻击 - 这些也很可能打破了整个系统，这对客户来说并不健康。 NAS是Mobotix IP cameras的存储，它运行大量依赖服务，并且已经在30多个对象中部署了单元而没有任何问题。简而言之，webserver不是提供网络，而是提供操作系统。
在写作之前，我补充说，快速测试，webserver明确地向sudoers - http - 没有用。
在RAID程序集流程中运行的最后一个命令是http ALL=(ALL) NOPASSWD: ALL，返回的退出代码为mount /dev/md/stone\:supershare /mnt/supershare。
执行后续安装会导致：
0退出代码为mount: /dev/md127 is already mounted or /mnt/supershare busy
/dev/md127 is already mounted on /mnt/supershare
。因此，阵列安装在某处。
在上述32之后执行umount /dev/md/stone\:supershare，返回退出代码mount。执行后续0会导致：
umount以上命令使用sudo自动运行。
所以，它已经成功安装并且已成功安装，但是......我在TTY0上以umount: /dev/md/stone:supershare: not mounted
身份登录，在执行root操作后运行lsblk但是，我看不到mount：
mountpoint从TTY0尝试相同的NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 55.9G 0 disk
├─sda1 8:1 0 1M 0 part
├─sda2 8:2 0 1G 0 part [SWAP]
├─sda3 8:3 0 12G 0 part /
└─sda4 8:4 0 16.6G 0 part /home
sdb 8:16 0 931.5G 0 disk
└─sdb1 8:17 0 899M 0 part
└─md127 9:127 0 1.8G 0 raid0
sdc 8:32 0 931.5G 0 disk
└─sdc1 8:33 0 899M 0 part
└─md127 9:127 0 1.8G 0 raid0
命令会成功安装（之后显示lsblk）。
如果我mount使用我的CLI工具，然后使用CLI工具运行mount和mount -l，则可以看到挂载点。
以root身份立即从TTY0运行两个命令，不显示挂载点。
重新启动，重置所有安装（不自动安装），然后从TTY0挂载并从TTY0运行lsblk显示挂载点。
然后，使用CLI工具运行lsblk，显示挂载点。
然后，使用CLI工具运行lsblk，退出代码umount - 已卸载。
再次使用CLI工具运行0，不显示挂载点。
从TTY0运行lsblk，仍会显示挂载点。
当使用我的CLI工具运行lsblk / mount时，它会私下为umount会话运行程序执行命令。
sudo，卸载它，但是再次 - 私下。
从CLI工具挂载RAID后，从TTY0登录umount并运行http，不会显示挂载点。 这种否定了“lsblk会话运行者私下执行”。
我还在IBM's中找到了一个材料：
mount命令使用真实用户ID而非有效用户ID 来确定用户是否具有适当的访问权限。系统组成员可以发出设备安装，前提是他们具有对安装点的写访问权以及/ etc / file systems文件中指定的安装。 具有root用户权限的用户可以发出任何挂载命令。
我希望我已经解释得足够好而且不会太混乱，我也希望你们能够帮我解决这个问题。
我尝试使用外部Web上下文的CLI工具进行测试，这是一个简单的PHP文件，我执行sudo和自定义用户。
在这两种情况下，安装和卸载都是成功的。所以，它必须是Apache执行命令的东西，但是，我不明白为什么其他命令可以工作。
是什么导致了这个问题，我该如何克服它？
答案 0 :(得分：3)
简而言之，hassle has been resolved。
这是Apache的相应systemd服务，具有PrivateTmp=true指令。显然，该指令使用新的文件系统命名空间执行该过程。
这个问题，在尝试调试和修复问题时，在互联网上产生了许多其他帖子。
每个来自我在此过程中学到的东西。
我首先了解mount处理EUID的更深入信息。很快，我发现我的简单sudo调用实际上并没有使用EUID 0执行。这导致我对如何执行此操作进行了多次查询，这反过来生成了命令语法，如sudo -i 'su' -c 'mount /dev/sdb1 /mnt/firstone'和其他派生词。
解决方案没有成功，我进一步观察。
我开始考虑尝试将条目添加到/etc/fstab，这导致了许多权限问题。此外，sudo和我的CLI工具证明该任务不完整。让我们带来大武器 - 让我们用-DBIG_SECURITY_HOLE编译Apache，也就是说，给Apache提供以root运行的可能性。
让我们向tab添加条目，让我们尝试装载......然后......失败！
经过多次测试，查询以及什么不是，我偶然发现了导致我here的per process mount并向我展示了namespaces的维度。
好的，这解释了一切 - 检查/proc/<pid>/mounts验证了它，现在，让我们更深入地了解如何克服它。
再次，经过多次尝试而没有成功，我开始根据我对名称空间的新知识发布问题。缩小问题并变得更具技术性（至少我认为我做过），这最终导致了pointed me进入systemd方向的用户hiciu，特别是Apaches服务 - PrivateTmp。< / p>
瞧！ ......显然systemd可以强制执行新的命名空间。
答案 1 :(得分：0)
我有同样的apache奇怪行为，花了超过3天的时间却没有任何有效的解决方案。然后我很幸运地找到了这篇文章，正如您所描述的，PrivateTmp引起了问题。就我而言，我尝试从php挂载驱动器：
<?php
...
exec("sudo mount /dev/sda1 /mnt/drive", $output, $ret);
...
?>
当我从Web浏览器运行以上代码时，exec函数返回0（成功），我什至无法在代码中列出映射的驱动器：
exec("ls /mnt/drive", $o, $r);
foreach ($o as $line){
echo $line.'<BR>';
}
但是当我尝试从cli搜索映射的驱动器时，看不到它。我尝试了一切，包括更改权限，更改php.ini等。没有任何帮助。到目前为止，更改
PrivateTmp=false
在
/lib/systemd/system/apache2.service
可以解决问题。非常感谢您的分享！
答案 2 :(得分：0)
它正在搜索，并且看起来该行为已通过chroot从php实现并检测到：
system('ischroot;echo $?');
设置为PrivateTmp = true时为0（表示“您在chroot中”），设置为PrivateTemp = false时为1。