Moved /var/lib/snapd into /home/snapd and symlinked back. Snaps fail to start

pc_magas1 · February 1, 2020, 1:08pm

Because in the partition my /var had been mounted, was rather small space I found out that /var/lib/snapd takes a huge chunk of space in it.

Therefore, I moved it into /home/snapd via rsync and symlinked it back:

sudo service snapd stop
sudo rsync -ravp /var/lib/snapd /home/snapd
sudo chmod --reference=/var/lib/snapd /home/snapd
sudo ln -s /home/snapd /var/lib/snapd

But that causes my snapd daemon to have the following issues:

sudo systemctl status snapd
● snapd.service - Snappy daemon
   Loaded: loaded (/lib/systemd/system/snapd.service; enabled; vendor preset: enabled)
   Active: active (running) since Sat 2020-02-01 14:51:52 EET; 13min ago
 Main PID: 1178 (snapd)
    Tasks: 18 (limit: 4915)
   CGroup: /system.slice/snapd.service
           └─1178 /usr/lib/snapd/snapd

Φεβ 01 14:56:29 dimitris snapd[1178]: snapmgr.go:267: cannot read snap info of snap "lxd" at revision 11348: cannot find installed snap "lxd" at revision 11348: missing file /snap/lxd/11348/meta/snap.yaml
Φεβ 01 14:56:29 dimitris snapd[1178]: snapmgr.go:267: cannot read snap info of snap "snapcraft" at revision 3970: cannot find installed snap "snapcraft" at revision 3970: missing file /snap/snapcraft/3970/meta/s
Φεβ 01 14:56:29 dimitris snapd[1178]: snapmgr.go:267: cannot read snap info of snap "skype" at revision 112: cannot find installed snap "skype" at revision 112: missing file /snap/skype/112/meta/snap.yaml
Φεβ 01 14:56:29 dimitris snapd[1178]: snapmgr.go:267: cannot read snap info of snap "kde-frameworks-5-core18-sdk" at revision 31: cannot find installed snap "kde-frameworks-5-core18-sdk" at revision 31: missing 
Φεβ 01 14:56:29 dimitris snapd[1178]: snapmgr.go:267: cannot read snap info of snap "brave" at revision 63: cannot find installed snap "brave" at revision 63: missing file /snap/brave/63/meta/snap.yaml
Φεβ 01 14:56:29 dimitris snapd[1178]: snapmgr.go:267: cannot read snap info of snap "gnome-3-28-1804" at revision 116: cannot find installed snap "gnome-3-28-1804" at revision 116: missing file /snap/gnome-3-28-
Φεβ 01 14:56:29 dimitris snapd[1178]: snapmgr.go:267: cannot read snap info of snap "core18" at revision 1668: cannot find installed snap "core18" at revision 1668: missing file /snap/core18/1668/meta/snap.yaml
Φεβ 01 14:56:29 dimitris snapd[1178]: snapmgr.go:267: cannot read snap info of snap "gnome-characters" at revision 399: cannot find installed snap "gnome-characters" at revision 399: missing file /snap/gnome-cha
Φεβ 01 14:56:29 dimitris snapd[1178]: snapmgr.go:267: cannot read snap info of snap "minetest" at revision 1370: cannot find installed snap "minetest" at revision 1370: missing file /snap/minetest/1370/meta/snap
Φεβ 01 14:57:16 dimitris snapd[1178]: 2020/02/01 14:57:16 Unsolicited response received on idle HTTP channel starting with "HTTP/1.0 408 Request Time-out\r\nCache-Control: no-cache\r\nConnection: close\r\nConten
lines 1-18/18 (END)

And I am unable to launch any snap installed application. So how I can configure my snap daemon to look into /home/snapd folder instead of /var/lib/snapd one?

mborzecki · February 3, 2020, 8:14am

AFAIK you should use a bind mount to do that. I suggest trying with the following mount unit:

# /etc/systemd/system/var-lib-snapd.mount
[Unit]
Description=bind mount snapd from /home to /var/lib/snapd

[Mount]
What=/home/snapd
Where=/var/lib/snapd
Options=bind

[Install]
WantedBy=multi-user.target
RequiredBy=snapd.service

Save it to /etc/systemd/system/var-lib-snapd.mount, then:

# remove the symlink
$ rm -f /var/lib/snapd` symlink
$ systemctl daemon-reload
# enable the mount unit
$ systemctl enable var-lib-snapd.mount

and lastly reboot.

@zyga-snapd may also have some suggestions here.

zyga-snapd · February 3, 2020, 12:15pm

Maciek’s suggestion is accurate. You can mount additional storage under /var/lib/snapd or anywhere in the /var hierarchy. Do to so please stop snapd, move /var/lib/snapd to something like /home/snapd and establish the bind mount as described above.

Out of curiosity, how much space did you devote to the partition encompassing /var?

Juanma · May 19, 2026, 1:44pm

When you guys mention folder /home/snapd, do you mean just a folder under /home, created and owned by root, or do you mean the home folder of a new user snapd?

I guess it is the former, because it seems like Snap requires the mount point of /var/lib/snapd to be owned by root, as I learned the hard way when I tried to run Snap with its library under my own home folder (I thought it was a good idea to mount it on ~/snap/snapd, but didn’t work).

ernestl · May 28, 2026, 2:46pm

Hi Juanma

Just move into a location in $HOME (your user home), and bind mount to that location.

[Mount]
What=<the location you prefer>     <=== just change this to preferred location
Where=/var/lib/snapd
Options=bind

Juanma · June 11, 2026, 8:46am

Hi, Ernest.

Have you tried that? I did, and it didn’t work for me. In fact, my advice would be don’t do precisely that.

The snapd directory must be owned by root, or perhaps by a user created for the task, with certain permissions and belonging to certain group(s). That is what I asked about.

I had to perform a reinstallation of the whole OS and I took these steps:

Created folder /home/snapd as root (sadly, I don’t remember if I did sudo mkdir or sudo su and then mkdir).
Copied everything from /var/lib/snapd to /home/snapd (I used cp -R).
Added bind mount line to /etc/fstab and rebooted.

It works, as far as I can tell.

ogra · June 11, 2026, 10:02am

If you would have used the mv command (which I assume Ernest assumed in his comment) the permissions stay exactly as they were and you do not needed to fiddle with them…

Like:

sudo mv /var/lib/snapd /home/

For your point 3 what Ernest said is exactly accurate then… Many users use it like that with a proper systemd mount unit…

Juanma · June 11, 2026, 10:42am

I performed the copy as root, and the copied files stayed root-owned. In fact, my current system is working with those copied, not moved, files. But you mean moving the folder itself, which would indeed have avoided the problem, I guess. Same would go for (recursively) copying the whole folder, rather than its contents.

In my first attempt I copied files in the same way and I run into trouble due to the ownership of the containing directory, which is why I wouldn’t recommend placing the folder-to-be-bind-mounted under your $HOME, or be aware to change its ownership to root before mounting it.

I am still curious if @mborzecki1‘s reference to folder /home/snapd is just a root-owned folder in the “home partition” (and just as well could be something like /home/more_var_stuff/snapd) or if that is the home directory of a snapd user, analogous to how MySQL was managed by a specific system user which wasn’t root (if my memory doesn’t fail).

I am assuming it is the former, because that is working for me.