I tried this on Silverblue and it didn’t work.
It uses ostree to manage system data and has a read only root.
I think the easiest way to do this would be to add a bind mount to the fstab or use a systemd mount file but when I tried this I ended up causing my system to fail to boot so I didn’t want to mess around after I recovered.
Edit:
I made a ticket for rpm-ostree to see if this sort of thing can be easier https://github.com/projectatomic/rpm-ostree/issues/1711
Thanks for letting us know, and for creating the ticket. I’ll add a note about Fedora Silverblue while we look into possible solutions.
After running
$ sudo dnf install snapd
the user is required to log out and log in again for the system to pick up the new $PATH. Else it is not possible to start snap apps via GNOME dash for example.
Might be obvious to some users, but took me the better part of an hour to figure it out. Maybe worthy to note it in the install docs.
Thanks for letting us know, and sorry for the omission. We’ll add this to the docs.
Logging out and logging back in is required for every distribution that doesn’t preload snapd for the binaries and stuff to work, since they don’t take effect until the profile is reloaded.
When I run sudo snap install hello-world
I get error error: system does not fully support snapd: cannot mount squashfs image using "squashfs": mount:
/tmp/sanity-mountpoint-620885772: unknown filesystem type 'squashfs'.
Hello - I’ve just tested this with a fresh install of Fedora 29 (workstation installation) and it worked as expected for me. Could you let us know which version of Fedora you’re running?
Fedora release 28 (Twenty Eight)
Thanks - I’ve just tried the same thing with 28 and it works for me:
[graham@fedora ~]$ sudo ln -s /var/lib/snapd/snap /snap
[sudo] password for graham:
[graham@fedora ~]$ sudo snap install hello-world
2019-03-15T11:44:36Z INFO Waiting for restart...
hello-world 6.3 from Canonical✓ installed
[graham@fedora ~]$ hello-world
2019/03/15 11:45:00.040691 cmd_run.go:367: restoring default SELinux context of /home/graham/snap
Hello World!
[graham@fedora ~]$ hello-world
Hello World!
Could you send us the output from snap --version? Mine looks like this:
$ snap --version
snap 2.37.4-2.fc28
snapd 2.37.4-2.fc28
series 16
fedora 28
kernel 4.20.14-100.fc28.x86_64
[root@0rcan0mic etc]# snap --version
snap 2.37.4-2.fc28
snapd 2.37.4-2.fc28
series 16
fedora 28
kernel 4.16.3-301.fc28.x86_64
Here is the actual error:
[root@0rcan0mic etc]# sudo snap install hello-world
error: system does not fully support snapd: cannot mount squashfs image using "squashfs": mount:
/tmp/sanity-mountpoint-257558992: unknown filesystem type 'squashfs'.Thanks! There’s a known issue with cloud installed Fedora (I’m guessing) - sorry for not communicating this, but it looks like there may be a kernel/driver/module version mismatch. It could be solved with a reboot, although we know this is problematic with cloud installs.
the reboot didn’t fix the issue.
snap installed on local machine though.
same issue in fed29 cloud version.
[root@localhost ~]# cat /etc/fedora-release
Fedora release 29 (Twenty Nine)
[root@localhost ~]# uname -a
Linux localhost.localdomain 5.0.6-200.fc29.x86_64 #1 SMP Wed Apr 3 15:09:51 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
[root@localhost ~]# snap --version
snap 2.37.4-2.fc29
snapd 2.37.4-2.fc29
series 16
fedora 29
kernel 5.0.6-200.fc29.x86_64
[root@localhost ~]# snap install hello-world
error: system does not fully support snapd: cannot mount squashfs image using “squashfs”: mount:
/tmp/sanity-mountpoint-500924499: unknown filesystem type ‘squashfs’.
I just hit this in a Fedora 31 cloud image.
Here’s an exact reproducer using Multipass:
$ multipass launch --name fedsnap http://download.fedoraproject.org/pub/fedora/linux/releases/31/Cloud/x86_64/images/Fedora-Cloud-Base-31-1.9.x86_64.qcow2
$ multipass exec fedsnap -- yum install snapd
$ multipass exec fedsnap -- snap install hello-world
error: system does not fully support snapd: cannot mount squashfs image using "squashfs": mount:
/tmp/sanity-mountpoint-156693269: unknown filesystem type 'squashfs'.
The workaround here is to:
$ multipass exec fedsnap -- yum install kernel-modules
$ multipass restart fedsnap
Thanks for this detailed report - I’ve just been through the process and encountered the same issue which your solution fixes. I’ll add this as a caveat to the docs - thank you!
when i try install riseup vpn i have error
$ sudo snap install riseup-vpn --classic
error: cannot communicate with server: Post “http://localhost/v2/snaps/riseup-vpn”: dial unix /run/snapd.socket: connect: no such file or directory
Hello - I’ve just tried the same with a couple of Fedora installations (28 and 32) and don’t encounter the problem.
Could you try the same command again (and maybe try installing the hello-world snap), and also provide the output from snap --version?
Hello I was able to solve the problem By following these steps (1,2,3) First: writing the following command $systemctl status snapd.service output well be like { $ systemctl status snapd.service ● snapd.service - Snap Daemon Loaded: loaded (/usr/lib/systemd/system/snapd.service; disabled; vendor preset: disabled) Active: inactive (dead) TriggeredBy: ● snapd.socket } Now we write the following command $systemctl start snapd.service it ask you for root password And for sure $systemctl status snapd.service output well be like {" $ systemctl status snapd.service ● snapd.service - Snap Daemon Loaded: loaded (/usr/lib/systemd/system/snapd.service; disabled; vendor preset: disabled) Active: active (running) since Wed 2020-06-10 13:34:31 EEST; 18min ago TriggeredBy: ● snapd.socket Main PID: 3462 (snapd) Tasks: 11 (limit: 6923) Memory: 45.0M CPU: 917ms CGroup: /system.slice/snapd.service └─3462 /usr/libexec/snapd/snapd
Jun 10 13:34:30 dhcppc7 systemd[1]: Starting Snap Daemon...
Jun 10 13:34:30 dhcppc7 snapd[3462]: AppArmor status: apparmor not enabled
Jun 10 13:34:31 dhcppc7 snapd[3462]: daemon.go:343: started snapd/2.45-1.fc32 (series 16; classic; devmode) f>
Jun 10 13:34:31 dhcppc7 snapd[3462]: daemon.go:436: adjusting startup timeout by 50s (pessimistic estimate of>
Jun 10 13:34:31 dhcppc7 systemd[1]: Started Snap Daemon.
Jun 10 13:34:42 dhcppc7 snapd[3462]: storehelpers.go:438: cannot refresh: snap has no updates available: "cor>
Jun 10 13:34:42 dhcppc7 snapd[3462]: autorefresh.go:397: auto-refresh: all snaps are up-to-date
[loaialnshar@localhost ~]$
"}
Now everything is ready for action
Note:You need to do this every time after turning on the computer
And I work on Fedora 32 KDE 
I followed this in a LXD container only to find that snaps built using the currently recommended compression (compression: lzo) fail to install.
The failure isn’t very informative:
$ sudo snap install ubuntu-frame-vnc
error: cannot perform the following tasks:
- Mount snap "mesa-core20" (125) (systemctl command [start var-lib-snapd-snap-mesa\x2dcore20-125.mount] failed with exit status 1: Job failed. See "journalctl -xe" for details.
A bit of digging into journalctl -xe found the following:
May 23 15:24:25 fedora-38 mount[355]: Squashfs image uses lzo compression, this version supports only xz,
zlib, lz4, zstd.
May 23 15:24:25 fedora-38 systemd[1]: var-lib-snapd-snap-mesa\x2dcore22-147.mount
: Mount process exited, code=exited, status=255/EXCEPTION
I’m not sure how many popular snaps use LZO, but this could well be a limitation worth noting.
After this: [quote=“degville, post:1, topic:6755”]
sudo ln -s /var/lib/snapd/snap /snap
[/quote]
You should run
systemctl enable snapdNo amount of restarts will make it work if snapd does not start on startup. Alternatively, you could start it manually:
systemctl start snapdUsing Rocky Linux 8.6