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 | Connection refused error |
| Slow snap downloads | Missing binaries |
| Home directory location | Domain served /home directories |
chmod errors |
Too early for operation errors |
| Generate debug info |
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.
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.
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.
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.
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-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.
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
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.
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 4 months ago. Help improve this document in the forum.
