Snap应用MuseScore绑定挂载异常问题求助

嘿，我来帮你捋捋这堆奇怪的问题，看起来是Snap的沙箱机制和你的bind mount撞车了～

1. 为什么umount提示「未挂载」但mount还显示？ #

这是因为你的挂载点被别的挂载给覆盖了！现在mount显示的/dev/sda3挂载，根本不是你原来设置的bind mount，而是某个操作（大概率是Snap应用的沙箱挂载机制）把挂载点所在的分区直接挂到了这个目录上，把原来的bind mount给“藏”起来了。这时候系统找不到你原来的bind mount条目，自然提示没挂载，但这个目录确实被新的挂载占着，所以mount还能看到。

你可以用findmnt /home/me/MuseScore3Development/Scores命令看更详细的挂载层级，肯定能看到多层挂载的情况，原来的bind mount被压在下面了。

2. 为什么源目录的文件不显示在挂载点？ #

道理和上面一样——现在挂载在这个目录的是/dev/sda3的分区挂载，不是你绑定的/path/to/real/files。这个新挂载的区域大概率是空的，所以你看不到源文件；而你从MuseScore存的文件，其实是写到了这个新挂载的分区区域里，和源目录完全没关系。

3. keyctl和这事有啥关系？ #

keyctl是Linux用来管理安全密钥的工具，Snap应用在沙箱里运行时，会用密钥来绑定挂载的安全策略，防止非法访问。当你尝试umount这个被Snap“接管”的挂载点时，系统发现还有关联的安全密钥没解绑，就会弹出这个提示。说白了就是这个挂载现在和Snap的沙箱权限绑定在一起了，直接umount会触发安全校验。

4. 可能的事件链和避免方法 #

大概率的事件序列： #

• 你一开始通过fstab设置了bind mount，MuseScore能正常访问源文件。
• 某次启动MuseScore时，Snap的沙箱机制自动对应用的默认数据目录（就是你设置的挂载点）做了特殊挂载处理，直接覆盖了你原来的bind mount。
• 之后这个挂载点就变成了Snap管理的分区挂载，和你的源目录彻底脱节。

怎么避免以后再踩坑？ #

• 别把bind mount设在Snap应用的默认数据目录里：Snap会对这类目录做自动挂载/隔离处理，很容易覆盖你的自定义挂载。换个非Snap管理的目录，比如/mnt/musescore-shared，然后在MuseScore里手动导航过去打开文件。
• 改用Snap的权限接口代替bind mount：如果MuseScore支持removable-media接口，执行sudo snap connect musescore:removable-media，这样应用就能直接访问外部目录，不用折腾bind mount。
• 如果非要用fstab：把挂载点设到系统级目录（比如/mnt/xxx），然后给Snap应用授权访问这个目录，或者在MuseScore启动前手动执行mount --bind /path/to/real/files /mnt/xxx，不要依赖fstab自动挂载。

备注：内容来源于stack exchange，提问作者spraff