如何使用自动挂载为特定用户可靠地保持网络共享连接？

我有一个Synology NAS和一个运行Plex和XBMC的Mac mini，后者可以从NAS流式传输内容。MM由于多种原因（例如，在更新/重启NAS之后，网络问题，OS X问题），经常会丢失与NAS的连接。

在尝试了针对此问题的几种解决方案之后，我终于遇到了内置的自动安装工具，该工具应该在连接断开时重新连接网络驱动器。我设置好了，它似乎起作用了。但是有一个烦人的问题：

我不确定该如何表达，但是自动挂载的共享似乎有时会进入某种非真正连接的状态。遍历共享时，它将立即连接。很好，但是共享仅针对访问它的用户安装。

我有两个用户帐户：运行Plex和XBMC并需要访问共享的TV，以及用于管理任务的Admin。有时，我也使用Admin帐户连接到NAS，但是我正在使用Finder。无需永久连接。

由于某种原因，我不明白，有时会为Admin帐户安装自动挂载的共享。这意味着电视帐户无法访问共享（权限被拒绝）。我可以umount与Admin共享，也ls可以与TV 共享，以便为后者安装它，但是一段时间后，Admin再次具有权限。

我怎样才能解决这个问题？如何设置权限，以便电视是唯一可以访问自动挂载共享的帐户？

这是我的自动挂载文件的样子：

auto_master

权限： -rw-r--r-- 1 root wheel

+auto_master      # Use directory service
/net              -hosts     -nobrowse,hidefromfinder,nosuid
/home             auto_home  -nobrowse,hidefromfinder
/Network/Servers  -fstab
/-                -static
/-                auto_nas   -nosuid,noowners

auto_nas

权限： -rw------- 1 root staff

/NAS -fstype=smbfs,soft smb://TV:@192.168.1.56/Files

/ NAS（挂载点）

权限： drwx------@ 1 TV wheel

MM正在运行优胜美地（10.10.3）。

假设您不希望启用“ root”用户登录功能并充分放开文件和目录权限，以至于有可能将您的系统打开到一个重要的安全攻击载体上（我假设正是...）， 2017年2月7日，您无法完成您描述的内容:(

至少对于AFP / SMB / CIFS共享而言不是（这是我测试过的仅有的三个，您在NFS数量上可能还有其他运气，但我不在网络上运行它们，因此无法确认）。

似乎有两个潜在的根本原因。一种是在优胜美地附近的某个时候，对使用直接与间接自动挂载功能之间的差异进行了一些修改，当一个以上的用户访问自动挂载的共享时，会导致间歇性故障。

从Sierra开始，此功能已完全中断，因为将特殊的/ Volumes目录的所有者设为“ root”用户，并且如果另一个用户被授予对该目录中该目录中任何文件夹或文件的所有权，则该用户将自动接管所有权。一点。 已提交错误，请随时发表评论并分享您的愤怒。

在此博客文章的评论部分中，讨论了使用自动挂载的几个示例（及其一些局限性），用户“ Mark”就跨多个用户共享自动挂载的文件夹提供了关于此问题的完整分析。

TL; DR-它在10.10左右被破坏，尽管在许多论坛上都进行了讨论，但Apple尚未承认该错误或致力于修复。

我认为10.11中发生了一些事情，该问题打破了将AFP共享安装到用户目录中的过程>。我正在尝试将afp：// user：pass@myserver.local/Music挂载到/ Users / me / Test

auto_master行如下：/-auto_afp -nosuid

auto_afp行如下：/ Users / me / Test -fstype = afp afp：// serveuser：servepass@server.local/Music

服务器安装精美，但是单击/ Users / me中的服务器图标会显示错误“无法打开文件夹“测试”，因为您无权查看其内容。”

解决问题后，我看到这是一个权限问题。挂载点具有所有者和组以及权限：drwx-@ 1 root wheel 364 31 Dec 10:01测试（实际上，这很有趣-如果我清空auto_afp文件并重新启动，它将返回到具有owner /的常规目录组/权限drwx—— + 18 me人员612 12月31日10:01测试）

因此，这里的问题是autofs使用root特权安装共享，而我的用户实际上无法使用共享。根据我在网络上的阅读，这似乎是一个相对较新的问题-也许与El Capitan有关？

为了进行比较，当我执行以下操作时（以用户身份，而不是以系统用户身份或使用'sudo'）：从位于/ Users / me的查找器中创建一个名为“ Test3”的新文件夹，然后从终端输入：mount -o nosuid -t afp afp：// serveuser：servepass@server.local/Music/Users/me/Test3

然后服务器安装得很漂亮（尽管查找程序名称为“ Music”，我希望更改它），并且具有以下用户/组/权限：drwx-@ 1 me staff 364 31 Dec 10:21 Test3，我是能够查看和操作内容。

因此，总而言之，问题是：如何获得autofs来安装网络AFP共享并将其映射到用户目录中，以便用户可以访问它并操纵其内容？从历史上看，我认为这确实应该是autofs的工作方式，但是似乎“ root wheel”对映射文件夹的所有权使它现在无法真正使用。

我正在做的另一件事是：我回到了上面概述的简单目标，但我的长期目标是将外部音乐文件夹映射到每个用户。auto_afp应该如下所示：

/ Users / me / Test -fstype = afp afp：// serveuser：servepass@server.local/音乐/ Users / her / Test -fstype = afp afp：// serveuser：servepass@server.local/音乐/ Users / him / Test -fstype = afp afp：// serveuser：servepass@server.local/音乐

我知道我可以在每个用户的登录项目中进行此装载，但这实际上不足以满足我的长期需求。长期来看，我需要此文件夹由autofs在启动时装入，以使其可用于云备份。

用户“ Ben”发表了评论，确认了这一分析，并回应说至少在他发表评论时，还没有解决方法：

使用间接映射也无济于事。至少在优胜美地，这种功能在OSX中似乎已经被破坏了……我已经研究了3年的同一个问题的帖子，据我所知，根本没有办法在所有共享点上共享安装点用户……这是一个巨大的，令人发指的，令人难以置信的失败。

谢谢苹果！

注意：我不建议任何网络使用此方法，因此此处将不提供有关如何操作的详细说明，但是同一注释板上的另一位用户表示启用root用户登录并使用该用户访问他的系统将允许该操作。按预期工作：

一种选择是启用root，然后以root登录。一旦完成，一切就开始起作用。我知道是垃圾选项，但我的用例是隔离网络上的媒体服务器。直到我能看到直到苹果让它摆脱困境才是唯一的选择。

每个人，Apple，安全专家等都强烈建议不要这样做，因此我认为这是解决此问题的可行途径。我们将不得不等到Apple发布修复程序。