网络共享：2026年仍在讨论

# 网络共享：2026 年仍在讨论 来源：https://pointieststick.com/2026/06/22/network-shares-still-talking-about-them-in-2026/ 到今天，很多人可能已经看过 Linus Tech Tips 的视频“Linux 很容易，对吧？（https://www.youtube.com/watch?v=bNpmB1heEF0）”？ 太长不看版：是的，大部分事情确实相当容易，他们遇到困难的任务也越来越少……但对于“prosumer/技术爱好者”群体——那些有一定到很强技术背景、但不是软件开发人员的人来说——痛点依然存在。 KDE 的表现相当不错，有一个例外：网络共享。 网络共享。 是的，网络共享。 还在讨论。在 2026 年！ 这到底是怎么回事？为什么这个问题还没解决？我们今天就来聊聊。 ## 在 KDE 的软件中是如何工作的 当你从 Dolphin 内置的网络共享浏览器访问一个网络共享时，它并不会挂载到本地某个路径；Dolphin 是使用自己的通信协议连接到共享的：`smb://`、`nfs://` 或类似的。 对于 KDE 应用来说这没问题；当你双击通过 Dolphin 访问的网络共享上的文件时，它们可以使用这些通信协议来访问文件。 一切正常。 当你双击网络共享上的一个文件，它在一个非 KDE 应用中打开时，此时一个叫做 `kio-fuse`（我们几年前做了大量工作来构建它 (https://bugs.kde.org/show_bug.cgi?id=75324)）的东西会在后台秘密地创建一个 FUSE (https://en.wikipedia.org/wiki/Filesystem_in_Userspace) 挂载点，并将文件的本地路径传递给那个应用，指向这个秘密的 FUSE 挂载点。 这样，非 KDE 应用就能像预期一样从本地路径打开文件，一切依然正常。 ## 才不是呢，你骗人！ 被你发现了！*如果你从 Dolphin 打开文件*一切正常……但是，如果你需要在应用的“打开”对话框中访问共享上的文件，或者使用应用的“保存”对话框将文件保存到共享上呢？ 嗯，那就变得复杂了。 **如果是 KDE 应用**，标准的 KDE 打开/保存对话框知道如何访问网络共享，因此你可以打开或保存新文件到那里。如果你已经在 Places 面板中为共享创建了书签（这是我们在 KDE Linux 中记录在案的建议 (https://linux.kde.org/docs/network-shares/#bookmark-the-server-for-later-use)），那么它已经在那里了；只需点击它连接到共享，然后导航到你想要的文件或位置。非常简单，一切正常。 一个为我的客厅 HTPC 创建书签的网络共享。可以从 Dolphin 和 KDE 打开/保存对话框中以相同方式访问。效果很好！听起来不错！那么复杂性在哪里？我们继续。 **如果是使用 KDE 打开/保存对话框的非 KDE 应用**，情况也是一样：从对话框中访问共享，一切正常。例如 VLC 和 LibreOffice（在 Qt 后端下运行时）。仍然没有复杂性…… **如果是使用基于 portal 的打开/保存对话框的非 KDE 应用**，那么在这里一切也很美好。应用向 XDG Desktop Portal (https://flatpak.github.io/xdg-desktop-portal/docs/) 请求打开/保存对话框；portal 提供 KDE 对话框；一切正常。在这方面，Flatpak 一直在鼓励采用基于 portal 的打开/保存对话框，这带来了非常好的体验：KDE 用户在几乎所有的 Flatpak 应用中都能得到 KDE 打开/保存对话框——这是我们多年来一直想要的！ 但现在我们遇到了问题： **如果是使用自己的非 KDE 打开/保存对话框的非 KDE 应用……** 那么一切都变得很糟糕。它的对话框看不到你添加到 KDE 对话框中的任何书签，并且期望你将共享本地挂载到某个地方。即使 `kio-fuse` 创建了一个挂载点，非 KDE 对话框也不会在侧边栏中很好地显示它！你必须知道挂载点的秘密位置（`/run/user/1000/kio-fuse-[something]`），并使用对话框手动导航到那里。 如果这些应用是以传统方式打包的，这已经够糟了。如果它们是 Flatpak，情况更糟：它们必须在安全沙箱中开一个洞，才能访问 `kio-fuse` 挂载点，否则即使你知道它的存在并手动导航到那里，也无法访问。大多数 Flatpak 应用是为 GNOME 自身挂载共享的位置开洞……但不是为 `kio-fuse` 挂载它们的位置开洞——也不是为你手动挂载的任何共享的位置开洞。 此外，GTK 打开/保存对话框内置的网络浏览功能也是坏的，除非应用的 Flatpak 打包再开一个沙箱洞用于网络访问——很多都没有！而自定义对话框可能根本没有这个功能。 真是一团糟。不幸的是，截至 2026 年 6 月（如果你稍后阅读，请验证），处于这种不幸情况的应用包括一些重要的，比如 Blender、GIMP、LibreOffice（来自 Flathub 或使用 GTK 后端）、OnlyOffice、Inkscape、Audacity、DaVinci Resolve 和 Gedit。 所以，这很糟糕。 **如果是命令行工具或守护进程**，那么一切都同样糟糕。前面的所有用例都涉及 GUI 工具访问或挂载网络共享；除非并且直到发生这种情况，否则 CLI 工具什么也看不到。就好像共享不存在一样。需要某种东西在登录时挂载共享。这种东西通常最终是由一个随机的互联网教程指导你修改 `/etc/fstab` 来实现的。 ## 为什么不直接用 /etc/fstab 那种老式方法挂载？ 嗯，这有几个问题——第一个是 `/etc/fstab` 是 root 拥有的，所以用它挂载网络共享需要管理员权限。这在多用户或受管理的系统上行不通。 你可以通过使用一个 GUI 工具来规避这个问题，该工具可以使用 Polkit 修改那个文件，然后附带一个 Polkit 规则来自动允许这个应用的修改请求——即使对于非管理员用户也是如此。 如果是密码保护的共享，你还必须以明文形式存储凭据；没有提供将它们存储在加密密码存储系统中的方式。 这简直是对安全的嘲弄，但即使可以接受，结果发现使用 `/etc/fstab` 挂载网络共享并非只有一种方法，而是大约有一万两千种方法。每个在线教程都给你一套略有不同的步骤，如果你做得不完全正确，最终可能会得到一个不可写的挂载点，或者在共享当时不可用时延迟启动过程，或者如果之后变得不可用，会导致应用挂起和冻结，或者其他不明显的、可能非常“有趣”的问题 (https://bugs.kde.org/show_bug.cgi?id=504984)。 要做到正确并非不可能，但你必须知道自己在做什么。所以你真的希望这个文件只由合格的人或组织来修改，并且不要进行你不完全理解的更改。 ## 我们如何修复这个问题？ 并非全无希望。幸运的是，KDE 刚刚从 Sovereign Tech Fund (https://kde.org/announcements/sovereign-tech-fund-invests-kde/) 获得了超过 120 万欧元的投资，其中包括用于改进 KDE 网络共享处理能力的资金！ 现在是全面披露的时候了：KDE e.V. 正在与我的公司 Techpaladin Software (https://techpaladinsoftware.com/) 签约，负责运行这个项目的一部分。网络共享是一个显著的细小的困扰，我非常兴奋能参与其中，最终把这个话题彻底解决。 我不是在微观管理这个项目；坦率地说，我没有时间，即使我想！所以到目前为止，我的参与主要是让聪明的人来负责，把他们召集到一个（虚拟的）房间里，让他们能够高效工作，并确保他们有足够的资金！这就是我所做的，而且我对团队充满信心。 以下是一些正在讨论的想法： 1. 让 Dolphin 和打开/保存对话框自动为最近访问过的网络共享创建临时书签，也许放在“最近”部分中。*这将消除手动为临时访问的共享添加书签的步骤。* 2. 让 Dolphin 和打开/保存对话框在访问每个共享后立即为其创建 FUSE 挂载点，而不是等到共享中的文件首次在非 KDE 应用中被访问时。*这将解决 CLI 工具的问题——前提是共享事先被手动访问过至少一次。* 3. 要么将 FUSE 挂载的共享暴露在系统上一个让传统 GTK 打开/保存对话框默认可以看到的位置，要么向 GTK 提交补丁，让 GTK 打开/保存对话框能在当前位置看到 `kio-fuse` 创建的网络共享挂载点。*这将把修复扩展到使用传统 GTK 对话框的非 Flatpak 应用。* 4. 如果用户手动书签了一个网络共享，让 `kio-fuse` 在登录时自动为其创建挂载点，类似于 Windows 上的“映射网络驱动器”。*这将消除“……前提是共享事先被手动访问过至少一次”这一限制条件。* 5. 为 Flathub 上仍在使用此传统对话框的应用提交补丁，让它们能看到 `kio-fuse` 挂载网络共享的位置。*这将把上述修复扩展到这些应用的 Flathub 包。* 6. 提交补丁，将剩余的应用迁移到使用基于 portal 的打开/保存对话框。*这将首先减少需要上述修复的 GUI 应用数量。* 7. 标准化这些 FUSE 挂载点的位置和挂载参数，这样你就不会遇到 GNOME 和 KDE 应用将同一个共享 FUSE 挂载到不同位置的情况。这简直是荒谬！*我不确定这在政治上有多大的可行性，但减少重复会很好。* 8. 如果 systemd 可用，考虑使用 systemd 挂载单元作为底层实现，并仅在无 systemd 的系统上使用当前的 `kio-fuse` 实现作为回退。*这将让我们使用已经标准化的系统和性能更好的远程文件系统内核驱动。而且这可能比 #7 更可行。* 很多想法。初步工作已经开始，我预计这将成为未来几个月的一个持续关注领域。 所以希望很快这个主题就能最终成为过去。我认为很明显 KDE 在网络共享方面还没有 100% 到位，我们可以做得更好。而且我们会的！