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 core20base 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.
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
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):
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.
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
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)