开头玩 Arch Linux 的 GNOME 桌面十有八九都会去 extensions.gnome.org 装扩展。结果分两种情况一种顺顺利利另一种就是开头这个吓人的红字报错——No such native application org.gnome.chrome_gnome_shell。我第一次遇到的时候还以为是浏览器插件坏了折腾半天卸载重装浏览器扩展一点用没有最后才搞清楚问题根本不在浏览器那边而是系统里少装了一个连接器。这个报错表面上是浏览器插件在喊“找不到原生应用”实际是 GNOME 浏览器集成扩展和系统守护进程之间的一座桥断了。Arch 用户遇到尤其多因为上游把老包chrome-gnome-shell换成了gnome-browser-connector很多人不知道这回事照着旧教程装完浏览器扩展却漏掉了系统端的新包于是报错就出现了。这篇文章就是把这座桥从头到尾拆开给你看从原理到修复命令再到验证步骤一步步讲清楚。适合刚接触 Arch GNOME 的新手也适合升级完系统后突然发现扩展网站连不上的老用户。对症下药之前必须先把报错为什么出现这件事说透否则解决了这次下次换台机器照样踩坑。1. 错误背后的原理拆解这是一座“断了的桥”1.1 “No such native application”到底是谁在报错先抛结论这个报错是浏览器扩展GNOME Shell Integration也就是常说的 chrome-gnome-shell 浏览器插件抛出来的不是 GNOME 桌面抛出来的。它的工作机制是你在浏览器里打开 extensions.gnome.org网页脚本通过浏览器插件向本机 GNOME Shell 的 D-Bus 服务发请求查询已安装扩展、安装新扩展。但浏览器有个安全机制——网页和本机程序通信不能直接乱来必须走“Native Messaging”通道。浏览器会去固定的几个目录里找一个特定名称的 JSON 清单文件清单里写着“这个原生应用叫什么名字、它的可执行文件在哪”。这个 JSON 文件就是关键。它注册的 native application 名是org.gnome.chrome_gnome_shell对应可执行程序一般是/usr/bin/chrome-gnome-shell或者新版包里的/usr/bin/gnome-browser-connector。如果浏览器翻遍所有目录都找不到名为org.gnome.chrome_gnome_shell的清单文件或者清单里声明的可执行文件不存在它就会原封不动地报出No such native application org.gnome.chrome_gnome_shell所以这句话不是“GNOME 崩溃了”也不是“浏览器坏了”而是浏览器在说“系统里没有注册这个原生消息主机我没办法帮你跟 GNOME 通信。”1.2 Arch 上为什么特别容易踩这个雷这个坑在 Arch 上发生率极高不只是新手很多老玩家换新机器也会中招。原因要从 Arch 的包历史说起。早年 Arch 仓库里有个叫chrome-gnome-shell的包负责提供这个 JSON manifest 和可执行文件。大概从 2022 年起上游项目改名重构新包叫gnome-browser-connector旧的chrome-gnome-shell被标记为废弃很多镜像源里直接就移除了。问题就出在这里新用户查攻略搜到一篇两年前的教程教程上写“执行sudo pacman -S chrome-gnome-shell”结果提示找不到包。有人改用 AUR 装旧包装上之后 manifest 路径不兼容照样报错。有些人装完gnome-browser-connector之后没重启浏览器浏览器仍然按旧缓存去找 manifest报错继续。更隐蔽的情况是你明明装了新包但浏览器是Flatpak 版比如 Flatpak 版 Chrome / Firefox它运行在沙箱里原生消息主机的搜索路径和普通系统版不一样系统里装的 manifest 它根本看不见于是继续报同样的错。还有一个高频场景刚升级完系统。Arch 是滚动更新一次大版本升级把gnome-shell、gnome-browser-connector都更新了但你的浏览器还开着旧进程加载的还是旧配置此时去扩展网站看可能就会偶发这个报错。1.3 用生活类比讲清 Native Messaging把这个机制类比成打电话订餐可能更好理解。浏览器是大酒店的前台网页GNOME Shell 后厨桌面服务。电话线是 D-Bus 总线。前台想点菜总得有个通讯录查到后厨的分机号。Native Messaging 就是那本通讯录JSON 清单文件就是通讯录里的一张名片上面写着“后厨分机号是 10086分派电话转接的程序在/usr/bin/...”。现在浏览器拿了名片本翻遍所有抽屉就是没有写着org.gnome.chrome_gnome_shell的那张名片——那它当然只能说“找不到这个原生应用”。要么名片本没买系统包没装要么名片被放到了另一个抽屉Flatpak 或路径错误要么名片上的号码作废了旧包残留指向不存在的二进制。这样理解之后排查和修复的方向就非常清晰了想办法让浏览器能找到一张正确的“名片”。2. 解决思路与工具选型先装对系统端包再装对浏览器插件2.1 Arch 上的唯一正确解法gnome-browser-connector从上游项目改名之后Arch 官方仓库里目前提供的包就是gnome-browser-connector。它做的事情和旧chrome-gnome-shell一样安装后会替你完成三件事在系统目录里放好 Native Messaging 的 JSON manifest提供/usr/bin/gnome-browser-connector可执行程序部分版本里也叫chrome-gnome-shell兼容命名启动一个 D-Bus 相关的辅助服务实际是配合 GNOME Shell 的远程扩展安装通道。所以在 Arch 上修复这个报错的第一步其实是两条命令这么简单sudo pacman -S gnome-browser-connector如果系统里还留着旧包先移掉sudo pacman -Rns chrome-gnome-shell但我不建议直接跑完命令就收工。因为有些服务器镜像还没同步完或者你之前从 AUR 装过特殊版本系统里可能残留多个 manifest 文件互相打架。建议先查一下当前状态再动手pacman -Qs gnome.*browser.*connector|chrome-gnome-shell看到安装的包名再接着往下做。如果提示两个包都存在务必把chrome-gnome-shell卸干净。2.2 浏览器端官方扩展插件务必装对系统端连接器只是“桥墩”浏览器端还得有一座“桥面”——GNOME Shell Integration 浏览器扩展。Firefox / Chromium / Chrome / Edge从 extensions.gnome.org 首页点击安装浏览器会自动识别并跳转到扩展商店页面Firefox 是 Add-ons 商店Chromium 系是 Chrome 网上应用店。安装完浏览器扩展之后它会在浏览器菜单栏出现一个 GNOME 图标点击后能显示已连接的 GNOME Shell 版本。这里有个容易忽略的点新版连接器对浏览器扩展的版本有最低要求。如果你浏览器扩展装的是很老的 10.x 版本与新gnome-browser-connector的通信协议对不上同样会出问题。解决办法是把浏览器扩展移除后重新安装拿到当前最新版。2.3 绕开浏览器的备选方案Extension Manager如果你就是不想折腾浏览器扩展或者想绕开整个 Native Messaging 机制Arch 社区有一个非常好用的第三方工具叫Extension ManagerAUR 里搜索extension-manager即可。它是原生 GTK 应用直接通过 GNOME Shell 的 D-Bus 接口管理扩展完全不依赖浏览器。我的看法是Extension Manager 更适合日常管理适合只想装几个扩展、不想被浏览器插件绑架的人。但浏览器集成方式也有优势——可以直接在网页上看截图、看评分、一键安装。这篇文章主要解决浏览器方式的报错所以 Extension Manager 作为后续的替代方案提一嘴不做展开。2.4 为什么“只装包”解决不了所有情况这里必须提一个关键认知装包只是把桥墩立起来桥面能不能对接还取决于运行环境。举个例子如果你的 GNOME Shell 版本过老比如还在 3.36而连接器对应的是 GNOME 42 的新协议即使 manifest 和可执行文件都正常浏览器扩展连上后也会在页面里提示版本不匹配。Arch 用户一般滚动升级不存在这问题但如果你用旧 ISO 安装后长期没升级就有可能出现。所以完整解决路径应该是确认系统包正确安装、旧包清除。确认浏览器扩展安装且为最新。重启浏览器必要时重启 GNOME Shell 或直接注销登录。回到扩展网站验证连接。3. 实操过程与核心环节实现从报错到成功安装的全流程3.1 第一步清理旧包、安装新连接器先打开终端执行下面的命令序列。我建议一步步来而不是一次性粘贴方便随时看输出。# 查看当前是否安装了相关包 pacman -Qs chrome-gnome-shell|gnome-browser-connector输出可能有三种情况只有gnome-browser-connector说明包没问题继续下一步查浏览器插件。只有chrome-gnome-shell说明是旧包直接移除然后装新。什么都没有这就是报错最直接的原因装新包即可。执行# 如果存在旧包先移除 sudo pacman -Rns chrome-gnome-shell # 安装新连接器 sudo pacman -S gnome-browser-connector安装完成后验证关键文件是否到位ls -l /usr/bin/gnome-browser-connector正常情况下会输出一个可执行文件。如果是旧包路径也可能是ls -l /usr/bin/chrome-gnome-shell然后检查 Native Messaging manifest 是否被正确放置到浏览器会搜索的路径。不同浏览器搜索路径不一样但 Arch 的包一般会同时装好几份。你可以用pacman -Ql查看文件清单pacman -Ql gnome-browser-connector | grep native-messaging常见的 manifest 路径有Chromium/etc/chromium/native-messaging-hosts/org.gnome.chrome_gnome_shell.jsonChrome/etc/opt/chrome/native-messaging-hosts/org.gnome.chrome_gnome_shell.jsonFirefox/usr/lib/mozilla/native-messaging-hosts/org.gnome.chrome_gnome_shell.json用户级目录~/.local/share/chromium/native-messaging-hosts/等看到对应文件存在就说明系统端的“名片”已经放进抽屉了。3.2 第二步重启浏览器刷新连接很多人装完包后兴冲冲回到扩展网站结果还是报同样的错。原因多半是浏览器没重启或者浏览器的原生消息主机缓存还在。正确操作顺序彻底关闭浏览器不是“关闭窗口”而是从进程层面退出。Firefox 可以直接退出菜单Chromium 系用CtrlShiftQ或在系统托盘退出。不确定的话终端执行pkill -f firefox或pkill -f chrome来收尾。重新打开浏览器打开https://extensions.gnome.org。此时如果浏览器没有 GNOME 扩展图标先安装/启用浏览器扩展网站顶部会提示你安装。点击浏览器工具栏上的 GNOME 图标正常应该显示“连接成功GNOME Shell 版本 xxx”。如果一次不行可以刷新页面后再试。这一步看似废话但根据我的经验至少有 1/3 的人卡在这里——装的包没问题就是没重启浏览器。3.3 第三步在扩展网站实际安装一个扩展做验证连接成功后随便挑一个热门扩展——比如User Themes或者Tray Icons——在网页上拨动开关。正常情况浏览器会弹出 GNOME 原生的系统对话框询问是否允许安装扩展选择允许之后扩展立刻生效。如果这一步出现“无法连接到 GNOME Shell”或者实际扩展没出现在系统里那问题可能不在 Native Messaging而在 GNOME Shell 侧的 D-Bus 权限或扩展版本兼容。可以回到桌面打开终端验证 GNOME Shell 的 D-Bus 服务是否正常响应gdbus call --session \ --dest org.gnome.Shell \ --object-path /org/gnome/Shell \ --method org.gnome.Shell.Extensions.List如果返回一长串 JSON 数组说明 DBus 服务正常。如果返回类似“Error: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown”的信息说明 GNOME Shell 根本没有在这个会话里运行或者你当前用的不是 GNOME 桌面会话——比如跑到 KDE 里装 GNOME 扩展那肯定连不上。3.4 第四步处理最难缠的 Flatpak 浏览器沙箱问题如果你用的是 Flatpak 版浏览器例如 Flathub 上的 Firefox、Chrome那情况会变得微妙。Flatpak 沙箱限制了进程对系统路径的访问浏览器在沙箱里找 Native Messaging manifest 时默认只能看到~/.local/share/flatpak/和~/.var/app/应用名/下的用户级目录系统级/usr/lib/...里即使装了包它也看不见。解决方案有两种选一种操作方案 A给 Flatpak 浏览器授权访问系统路径不推荐破坏沙箱语义用flatpak override把/etc、/usr/lib等路径暴露给应用治标不治本而且沙箱内权限放开会有安全风险。方案 B不用 Flatpak 版浏览器用系统原生包Arch 官方源的firefox、chromium、google-chromeAUR都是普通包直接运行在宿主环境能正常读取/usr/lib等系统路径最省心。我的建议就是别为这事折腾 Flatpak 覆盖Arch 用户直接用 pacman 装浏览器才是正路。3.5 验证清单一张表确认每个环节检查项命令 / 位置期望结果连接器包已安装pacman -Q gnome-browser-connector输出包名和版本旧包已移除pacman -Q chrome-gnome-shell提示未安装或报错找不到可执行文件存在ls -l /usr/bin/gnome-browser-connector文件存在且有 x 权限Firefox manifest 存在/usr/lib/mozilla/native-messaging-hosts/org.gnome.chrome_gnome_shell.json文件存在Chromium manifest 存在/etc/chromium/native-messaging-hosts/org.gnome.chrome_gnome_shell.json文件存在GNOME Shell 正常响应上面那条gdbus call返回 JSON 数组浏览器扩展已连接打开 extensions.gnome.org工具栏图标亮/页面顶部显示已连接4. 常见问题与排查技巧实录4.1 高频报错的速查表我收集了几个实际踩过的坑把症状和解决办法放一张表里方便直接对照症状原因解决办法报错No such native application系统端包没装sudo pacman -S gnome-browser-connector报错No such native application但包已装浏览器未重启彻底退出浏览器重新打开包已装、浏览器已重启仍报错旧包残留 / 多个 manifest 冲突sudo pacman -Rns chrome-gnome-shell确认无残留只有 Firefox 报错Chromium 正常Firefox 首次使用原生消息时被用户拒绝浏览器弹窗允许/重启或重新安装浏览器插件Flatpak 浏览器始终连不上沙箱隔离看不到系统 manifest换成 pacman 系统版浏览器能连上但扩展页面说“版本不兼容”GNOME Shell 与连接器版本差距过大完整系统升级sudo pacman -Syu想装扩展但网页安装后桌面看不到浏览器扩展与系统连接器通信中断按流程重新执行第 3 节完整步骤4.2 排查思路三层递进法遇到这个报错不要病急乱投医。我推荐三层递进排查法第一层查物理存在manifest 文件在不在可执行文件在不在。用ls和pacman -Ql确认。如果文件都不全补装包即可。第二层查桥面对接浏览器是否读到 manifest。这层不好直接观察但可以借助浏览器的原生消息日志来辅助判断。Chromium 系的调试方式是在地址栏输入chrome://extensions打开“GNOME Shell integration”的服务工作者Service Worker控制台看控制台里有没有关于 native messaging 的错误Firefox 则在about:debugging里找扩展的“调试”按钮同样看控制台日志。第三层查对端状态GNOME Shell 的 D-Bus 服务是否正常。用前面说的gdbus call命令测试。如果 D-Bus 都连不上前面两层查得再仔细也白搭。举个例子我见过一个兄弟他系统里 manifest 文件齐全浏览器扩展也重装了好几次就是报错。我让他查 D-Bus发现 GNOME Shell 进程根本挂掉了一直在崩溃重启。把抽风的第三方扩展卸掉、重启 GNOME Shell 后浏览器那边什么都不用改就好了。这个案例充分说明排查顺序有多重要——不要只盯着浏览器报错信息本身。4.3 独家避坑关于org.gnome.chrome_gnome_shell这个名字本身有个细节值得多说一句。这个 native application 的名字始终是org.gnome.chrome_gnome_shell即使新包叫gnome-browser-connectormanifest 文件名也是这个名字——不能改。浏览器通信协议里要求的是这个名字改了名字浏览器就找不到。我之前见过有人尝试“优化”把 JSON 文件改成了org.gnome.browser_connector.json结果可想而知报错更严重。所以记住了manifest 的文件名和 JSON 里name字段都必须保持org.gnome.chrome_gnome_shell不变。这个名字是协议层面的兼容约定不是随便起的。如果你想手动检查某份 manifest 是不是这份协议用cat看看cat /usr/lib/mozilla/native-messaging-hosts/org.gnome.chrome_gnome_shell.json正常内容类似{ name: org.gnome.chrome_gnome_shell, description: GNOME Shell browser integration, path: /usr/bin/gnome-browser-connector, type: stdio, allowed_origins: [ chrome-extension://likdammnmodgmhdjajnnbcniklmaeggm/, moz-extension://... ] }如果path指向的文件不存在或者name变了那浏览器一定报错。这种手动审查的方法是我在排查环境差异比较大的机器时最常用的招。4.4 升级系统后的“隐性复发”Arch 滚动更新的特性决定了这个报错不会一次性解决。下次sudo pacman -Syu之后如果gnome-browser-connector更新但浏览器还开着连接可能短暂失效。这通常不是大问题关闭浏览器重开就恢复。如果你习惯长时间不关浏览器且启用了“休眠标签页”类功能旧标签页里的扩展页可能一直保持旧状态这时候在扩展网站刷新一下页面基本就好。另外一个常见诱发情况升级后gnome-shell进入新的大版本比如 45 升 46此时不仅连接器要更新部分旧扩展也可能不兼容导致桌面报错。这不是 Native Messaging 的问题是扩展本身的兼容问题别混淆在一起排查。4.5 手动注册的终极方案不推荐但值得会如果安装了包仍然无法让浏览器识别最后一招是手动注册用户级 manifest。这个方法适合极少数包管理器无法满足需求的场景比如你自己编译安装了 Docker 容器里的连接器。原理很简单浏览器在用户目录里也会搜索原生消息清单。对 Chromium 系把 JSON 文件放到~/.local/share/chromium/native-messaging-hosts/即可对 Firefox放到~/.mozilla/native-messaging-hosts/对 Chrome 则是~/.config/google-chrome/NativeMessagingHosts/。放好之后让 JSON 里的path指向真实存在的可执行文件。但我不推荐日常使用这个方案因为手动注册的 manifest 不会随系统包升级更新哪天连接器更新了你手动注册的内容还指着一个旧路径反而留下隐患。了解它是为了在极端情况下能自救正常还是靠包管理器。5. 写在最后的一些实在话我自己第一次调到这个坑时花了整整一个晚上从浏览器扩展改成 AUR 版旧包又从旧包切回官方新包最后发现就是没重启浏览器。第二天想想又气又笑。后来我养成一个习惯凡是遇到“No such native application”这类报错先问自己一句协议对端的系统包装了没、服务起了没而不是死磕报错客户端本身。这个方法不只适用于 GNOME 扩展Chrome 的 gpg 密钥集成、VS Code 的 git 凭据助手背后的 Native Messaging 机制如出一辙。报错里那个org.gnome.chrome_gnome_shell就是一个注册名学会用pacman -Ql反查包内文件、用gdbus验证远端服务基本上任何同类问题你都能自己排查。如果只是想快速装扩展我的建议是直接用 Extension Manager 这种原生工具省心。要是你更习惯网页浏览找出感兴趣的扩展那就按本文这套步骤来把包装好、浏览器重启彻底、D-Bus 服务确认正常这三板斧下去报错基本上不会再出现在你面前。顺带说一句升级系统后如果又碰到这个报错先深呼吸把浏览器关了再重开别急着重新装包。我这个过来人已经把弯路替你走完了你要做的就是记住这条捷径。