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.

For help with Robot Operating System (ROS) issues, see ROS Troubleshooting.

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.

1. Restart snapd:

   sudo systemctl restart snapd snapd.socket
   

2. Reload systemd’s daemon state:

   sudo systemctl daemon-reload
   

3. 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 tasks <change-id> 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.

GitHub builds have old account details

If your Ubuntu One account details change after Build from GitHub has been configured, the new account details are not reflected in the packages built and published from GitHub.

Due to the nature of the GitHub to Snapcraft authentication link, account details are retained for the lifetime of that link from the point of its creation. To force an update after changing your publisher details, you need to recreate that link as follows:

• For each snap that you control:
  • Go to the Build tab (https://snapcraft.io/<SNAP-NAME>/builds)
  • Select “Disconnect repo”
• Sign out of snapcraft.io AND login.ubuntu.com
  • For good measure, purge all cookies
• Sign back into snapcraft.io
• Confirm that your account name and other details are correct
• For each snap that you control:
  • Go to the Build tab
  • Select on the GitHub “Log in” button and reconnect to the appropriate GitHub repo

This should trigger a new build of each snap, with your new publisher details.

Last updated 3 months ago.