Snapd maintains a persistent mount namespace for each snap instance, that is for each snap or each parallel install of a given snap. The namespace is constructed automatically for the first invocation of application, including service, or hook that executes within the context of a particular snap.
All mount namespaces are persisted as bind-mounted fragments of the nsfs, namespace filesystem, a pure-in-memory file system supported by Linux, stored over empty placeholder files stored in the /run/snapd/ns directory.
Whenever a new snap hook or application is started, part of the startup logic inspects the persisted mount namespace to decide if it is applicable or if it should be discarded and re-constructed. At present the following conditions cause a snap namespace to be automatically re-constructed.
- The
base:of the snap has changed. For example a snap may be moving fromcore22tocore24. - The
base:snap used by the application snap has refreshed. This is very easy to trigger by configuring the corresponding base to follow thelatest/edgechannel. Note that if that base is also used as boot base of theubuntu-coresystem, then the system will also reboot after each refresh, masking the problem.
Whenever one of the two conditions occurs, the newly started process will inhabit a distinct mount namespace from all other processes that endure snap refreshes.
One particular consequence of this mount namespace decoherence, is that snaps using the mount-control interface, without the persistent attribute set to true, will no longer agree as to what file systems are mounted.