It would be great if i can install some snap on other drive or location.
For Example, a Game of 1gb, i don’t wanna install it in my OS location i would rather install it in other location.
Would be great if we can select it from Gnome-Software!!
1 Like
This is a feature that is unlikely to come in the near future, as it implies having to have per-snap storage locations, which increases the complexity and creates a relevant potential for bugs without a significant benefit for most users, in the sense most people installing 1GB snaps will do so on a machine that can take it.
Note that it’s relatively easy to move all snap files to a different location, by just mounting /var/lib/snapd/snaps elsewhere. The data will typically live in /var/snap.
I have tested the ‘mount --bind /source.directory /var/lib/snapd/snaps’ method with Ubuntu 14.04.5 LTS on VirtualBox.
Snap then throwed the ‘Invalid cross-device link’ error under some circumstances.
Binding the whole parent directory ‘/var/lib/snapd’ instead of only the subdirectory '/var/lib/snapd/snaps’ worked afterwards.
If you suffer ‘broken’ snaps, see All snaps showing as ‘broken’
There is another option available for storing ‘all’ of your snaps which, having been forced to find more space for /var/snap, seems to be working. (Saying seems because I don’t have long term usage for proof just that everything seems to be working after the change.)
(At a mentor’s (an old time unix geek) suggestion!)
First make sure that ALL of your containers have been stopped.
Copy /var/snap to another directory that has lots (LOTS!!!) of space in it.
Then you need to rm -r the original.
Lastly you need to create a hard link between /var/snap to /mynewdirectory/snap - - - I used $ ln -s /mynewdirectory/snap /var/snap .
I now did a reboot using shutdown -r now to clear any caches and to set things (as advised by my mentor).
(After the reboot completes.) You now need to start all your containers.
Should be working (at least in my case everything is working - - - grin!).
The question and the suggestions before yours address the storage of the snap itself, not their data.
Also, note that the /var/snap can simply be mounted as a different filesystem, as usual in this kind of scenario. It cannot however be a hardlink, because hardlinks do not work for directories. The “-s” in that command means symbolic.
There’s also no need to have “lots” of space, unless the applications in use require lots of space. This is true and general for any application used anywhere.
Using symlinks will fail on rbind-ing /var/snap into a snap-specific tmp dir:
sudo snap install lxd
error: cannot perform the following tasks:
- Run configure hook of "lxd" snap if present (run hook "configure": cannot perform operation: mount --rbind /var/snap /tmp/snap.rootfs_IMy4UQ//var/snap: Permission denied)
Using bind mounts failed for me too in a different way (not sure why, but likely because of nested bind-mounting).
/etc/fstab:
/mnt/sc1/var-snap/ /var/snap/ none defaults,bind 0 0
/mnt/sc1/var-lib-snapd/ /var/lib/snapd none defaults,bind 0 0
I have a hardware RAID-5 with a lot of space available represented as a single block device. Having partitions with separate file systems on it for /var/snap and /var/lib/snapd isn’t great because I have to manage partition size in advance.
I solved it for now using btrfs with separate subvolumes used for snap purposes.
/etc/fstab:
UUID=ae30a62b-db2f-4e50-ad63-e8c81bcf7781 /var/snap btrfs subvol=snap 0 0
UUID=ae30a62b-db2f-4e50-ad63-e8c81bcf7781 /var/lib/snapd btrfs subvol=snapd 0 0
There is a trade-off in this as if I lose the RAID for some reason I will no longer be able to use snapd. Still, having all data stored on rootfs isn’t suitable as it is a small-size SSD device in my case and I need to be able to store a lot of data on a separate device.
To my mind this would be quite common on routers or other small devices that have a limited amount of space in their internal flash memory so it deserves a feature or at least documentation for better UX.