Troubleshooting
Snaps run on, and are built for, a diverse and constantly evolving set of operating systems and embedded devices.
The vast majority of our users and developers experience very few issues, but any technology this complex and diverse will likely encounter some issues and incompatibilities.
This page attempts to guide users to either an appropriate solution to their issues, or the correct forum/thread where they can get help.
Snap developers experiencing issues should take a look at Troubleshoot snap building.
Network access
Both the snap daemon (snapd) and Snapcraft require network access to install, update, build and publish snaps. Local network and port configurations can affect their access.
See Network requirements for which hosts and ports are required to ensure consistent communication.
Cannot communicate with the server / connection refused
To perform most actions, the snap client needs to communicate with the snap daemon. If this isn’t possible, the snap command fails and outputs a connection refused error.
There are various causes for this error. Try the following steps, and if the problem persists, see the next section on generating and sharing debugging details.
-
Restart snapd:
$ sudo systemctl restart snapd snapd.socket -
Reload systemd’s daemon state:
$ sudo systemctl daemon-reload -
Reboot the machine:
$ sudo reboot
See cannot communicate with server connection refused for discussions on this issue.
Empty response from the server
When building a snap, you may occasionally see an empty response from the server error in the build log output, such as the following:
error: cannot refresh "core20": unexpectedly empty response from the server (try again later)
Error while refreshing snap 'core20' to channel 'latest/stable'
Run the same command again with --debug to shell into the environment if you wish to introspect this failure.
This error isn’t a problem with the snap build, or with its snapcraft.yaml, but is instead a symptom of updates to the core18 or core20 base snaps being only part-complete; the metadata has been updated, but the actual package is still being distributed across the installation base. The solution is to wait a few minutes and try again.
Slow snap downloads
When a snap is installed, it’s downloaded and authenticated against one or more servers attached to the Snap Store (or a local proxy). If a server is unavailable, or suffering bandwidth issues, installation progress will be slow.
You can check on the operational status of the servers attached to the Snap Store from the Snap Store status page: https://status.snapcraft.io/.
The Snap Store Status page also includes a status history for the servers over the last week and an incident history.
Additionally, there’s an RSS feed that tracks the current Snap Store Status. This can be subscribed to from any RSS client or hosted service.
See Extremely slow snap downoads for further discussions on snap download speeds.
Missing binaries / command not found
When the snap daemon is installed, its executable components are added to the system path ($PATH). If this doesn’t happen correctly, a warning is issued stating that snapd cannot be found.
The first thing to do is check installation instructions for the specific operating system. See Installing snapd for further details.
Linux distributions differ, but most will need a restart after snapd has been installed to refresh paths and system security profiles.
Executables from installed snaps can usually be found in /snap/bin/, and this should also be in your path. You can check this by typing echo $PATH | grep "snap/bin" on the command line, or by using the which command to see where the executable binary:
$ which spotify
/snap/bin/spotify
If an executable isn’t in your path, try using the snap run command, such as snap run spotify.
You can also manually add /snap/bin to your system $PATH. This is typically accomplished by adding a line similar to the following in your shell environment’s configuration file (such as ~/.bashrc or ~/.zshrc):
export PATH="/snap/bin:$PATH"
You will need to restart your shell for the changes to take effect.
Home directories outside of /home
The snap daemon (snapd) requires a user’s home directory ($HOME) to be located under /home on the local filesystem. This requirement cannot currently be changed. However, it is possible to bind mount an alternative $HOME location to /home to allow other locations to be found by snapd. This process is outlined below.
See Home directories outside of ‘/home’ for further details.
Domain served /home directories
Domain-mounted home directories beneath /home/<DOMAIN-NAME> may require extra AppArmor permissions.
These can be granted by running sudo dpkg-reconfigure apparmor and entering /home/<DOMAIN-NAME>/, replacing with your domain, as an additional home directory location at the prompt.
chmod errors
There is a known issue affecting some Debian 10 users, alongside some other Linux distributions users.
Snaps that depend on a browser-sandbox, such as Teams and Chromium, may inadvertently exit without an error, although logs should reveal an incorrect chmod (4755) error caused by the following system call:
clone(child_stack=0x7ffc0ea30060, flags=CLONE_NEWUSER|SIGCHLD) = -1 EPERM (Operation not permitted)
As a temporary solution, the issues can be bypassed with the following command:
$ sudo sysctl kernel.unprivileged_userns_clone=1
Too early for operation errors
After installing the snap daemon, snapd, it can take a short amount of time to initialise its environment.
During this initialisation period, if certain instructions are attempted either from the snap command or the REST API, the following error may be generated:
error: too early for operation, device not yet seeded or device model not acknowledged
The solution to errors like these is simply to wait a short while before attempting the same instruction again.
Generate debug info
One of the best ways to solve an issue is to understand when and where the error is encountered, and there are several levels of output that can be generated.
The snap changes and snap change <num> commands, for example, output details about what changed during the last refresh:
$ snap changes
ID Status Spawn Ready Summary
2052 Done today at 09:34 BST today at 09:35 BST Auto-refresh 7 snaps
2053 Done today at 15:16 BST today at 15:17 BST Refresh snaps "gnome-calculator", "flock-chat", "gnome-characters", "gnome-system-monitor"
The snap daemon documents its operations to the system log. This can be retrieved and viewed with the following command:
$ sudo journalctl --no-pager -u snapd
The snap debug command can be used to probe the state of the daemon:
$ sudo snap debug state /var/lib/snapd/state.json
ID Status Spawn Ready Label Summary
2955 Done yesterday at 13:53 BST yesterday at 13:53 BST hotplug-remove-serial-port Remove hotplug connections and slots of device /dev/ttyACM0 (Keyboardio Model…; serial: Ckbio01E) with interface "serial-port"
Don’t forget to include the output from sudo snap version if you wish to share your output to get further help on the forum.
Last updated 11 days ago.