Move snap packages to another location/directory

Solution 1:

Change snaps installation directory

This is a common issue that many ask for. It seems snap developers are not intending to solve it soon, so some solutions were suggested.

The first solution that was strongly refused by the community, but I didn't try, is to use symbolic links to link the directories that lead to snaps. This method seems not to work as the community replies says that AppArmor does not work with symbolic links.

The Second solution is mount --bind the directory /val/lib/snapd/snaps which works fine for me with the already installed applications but failed to install new applications because I was moving the directory to another partition. That gave me an error about hard linking the snap application with the cache directory which is located in /var/lib/snapd/cache. I don't know if this solution may work if the location are in the same partition or not; but this is the reason why I am moving the snap directory to free some space from partition to another one.

Third and working option is to move the /var/lib/snapd directory as a whole then mount --bind to it from another location and that worked for me and here is the steps.

Just a small note, you already know, after the rsync is done in the below steps, you can backup the data inside /var/lib/snapd to another location until the whole process is successfully done then you can remove the backup data if you want to free more space but keep /var/lib/snapd directory itself even free, as it is used by the mount point.

##############################################################################
# Take Care this section may break your System !!!
##############################################################################
##Move snap folder to Home instead of root.
#Create the directory : you can change the location
mkdir -p /home/$USER/snap/snapd

#Stop auto-updating (will *not* crash snaps already open)
sudo systemctl mask snapd.service
sudo systemctl stop snapd.service
sudo systemctl disable snapd.service

#Copy the data
sudo rsync -avzP /var/lib/snapd/  /home/$USER/snap/snapd/

#Do backups
sudo mv /var/lib/snapd /var/lib/snapd.bak
sudo cp /etc/fstab /etc/fstab.bak

#Change fstab (Change $USER with your name or change the path totally)
echo "/home/$USER/snap/snapd /var/lib/snapd none bind 0 0" | sudo tee -a /etc/fstab

#remount fstab Or reboot.
sudo mkdir /var/lib/snapd
sudo mount -a

if ls  /var/lib/snapd/ | grep snaps
then
    echo "Re-mounting snapd folder is done successfully. !!!!"
    sudo rm -rf /var/lib/snapd.bak
else
    echo "WARNING : Re-mounting snapd folder failed, please revert !!!!! "
    echo "WARNING : Re-mounting snapd folder failed, please revert !!!!! "
    echo "WARNING : Re-mounting snapd folder failed, please revert !!!!! "
    echo "WARNING : Re-mounting snapd folder failed, please revert !!!!! "
    echo "WARNING : Re-mounting snapd folder failed, please revert !!!!! "

    # Trying to revert automatically
    sudo cp /etc/fstab.bak /etc/fstab

    sudo mount -a
    sudo umount /var/lib/snapd

    sudo mv /var/lib/snapd.bak /var/lib/snapd

    echo "Files located at ~/snap/snapd should be removed, but are kept for
    recovery until you, manually reboot the system and make sure the service
    is running correctly. Then you can manually remove the folder ~/snap/snapd
    !!!!!!!!!!!!!!, you should do that manually."

fi

#Restart auto-updating
sudo systemctl unmask snapd.service
sudo systemctl start snapd.service
sudo systemctl reenable snapd.service

##############################################################################
# Take care the previous section may break your System !!!
##############################################################################

References

1. Custom disk location for certain snaps issue
2. ask ubuntu Question (Not best solution) Link
3. Suggestion to use bind mount instead of symbolic links in moving snap directories Link
4. Differences between bind mount and symbolic links Link
5. Make bind mount permenant

Solution 2:

I found this way...

• First move the snap package to desired location. Let snap_app.snap as the app you want to move. Move the package from /var/lib/snapd/snaps/snap_app.snap to ~/snaps/snap_app.snap.
• Then you have to change mount option in /etc/systemd/system/snap-snap_app-90.mount,number in the file name may be vary. It has directive What=/snap_app_loaction under [Mount]. Change it to your new snap package location.
• Finally you have to symlink the snap package to /var/lib/snapd/snaps/.
  Ex: ln -s ~/snaps/snap_app.snap /var/lib/snapd/snaps/snap_app.snap

Snap package is originally mount in to /snap/snap_app directory. you can check it with mount. Reboot your machine and you are all done.

Solution 3:

My snap experience with the VLC Player snap

Requirements. I wanted to 'clone' the VLC snap install from one Ubuntu 18.04 sytsem to another. Reasons. Limited internet allowance and bandwidth.

I followed the steps written by @Lakindu-Akash. Thank you. This gave me a good starting point into the world of snap installs. I found I had duplicate VLC snaps. See bellow.

Cleaned 1) /snap/vlc$ ls 1620 1700 current /snap/vlc$

1700 was current. I deleted the 1620 directory and contents.

2)In /etc/systemd/system$ I had snap-vlc-1620.mount snap-vlc-1700.mount

so I deleted the 1620 nount here.

/etc/systemd/system$ sudo rm snap-vlc-1620.mount

3) In /var/lib/snapd/snaps$

I had -rw------- 1 root root 305086464 Aug 00 00:00 vlc_1620.snap -rw------- 1 root root 304545792 Jul 15 2020 vlc_1700.snap

I deleted the vlc_1620.snap here which is the actual snap downloaded file.

/var/lib/snapd/snaps$ sudo rm vlc_1620.snap

4. On the new system Copying the files and directories to the new system, keeping the same locations did not work. I did not manually try to create a new mount point. Maybe it would have worked had I done this.

After reading through the snap forum, thank you @adam-monsen , I decided to do an install from the snap file located in /var/lib/snapd/snaps$ where the actual downloaded VLC snap file is and not an inode(pointer).

I copied the vlc_1700.snap to the new machine and ran from within this directory the command

sudo install snap vlc_1700.snap --dangerous

where vlc_1700.snap is the name of the snap (image or what you call it) Apparently this install will never update as I did not use the ack number? I have to learn about ack and it's usage. The install however went fine and VLC works on the new system. I will go out on a limb and say this could be helpful if you wanted to re-install on the same machine as well, to a different location. This being because the new snap image gets created in the directory where the install snap image is located and the installed process launched.

Solution 4:

Before you move folders please be advised and warned there is active heavy machinery (active directories) with moving parts you need to watch carefully for before taking any action.

Risk of www.Snapcraft.io blindsiding users in the middle of a transfer is a catastrophic failure of data loss, from running multiple sync processes for the same data, which if it breaks MySQL (all the time in Cloud data centers), will definitely break a user too.

"MASK/STOP/DISABLE" BEFORE YOU TOUCH ANYTHING, USE THESE COMMANDS:

# Stop "auto-upgrade"/"auto-update" Snapcraftiness
sudo systemctl mask snapd.service
sudo systemctl stop snapd.service
sudo systemctl disable snapd.service

*Will NOT crash snaps already open.

AFTER YOU'RE SURE IT'S OKAY, SET BACK TO NORMAL SETTING:

# Start back the "autoupgrade"/"autoupdate" Snapdiness
sudo systemctl unmask snapd.service
sudo systemctl start snapd.service
sudo systemctl reenable snapd.service

All 3 commands "MASK/STOP/DISABLE" are necessary given the contusion and terror represented by How to stop snapd from auto-updating? answers, which show not a single individual can speak authoritatively about how to address this issue. Like the question I am answering here, a simple move operation, the surrealy time-consuming and unpredictable effort to stop snapcraft from being crafty is an impediment.

I commented Move snap packages to another location/directory "Riskwise, does it matter if Snapcraft it [is] active (How to stop snapd from auto-updating?) during Rsync behaviors? Snap does not give predictable timing, and can push random updates during this parallel (r)sync, leading to catastrophic data loss in that important edge case? I edited the script at askubuntu.com/review/suggested-edits/1167854 with sudo systemctl mask/stop/disable snapd.service before, and sudo systemctl unmask/start/reenable snapd.service after, in an abundance of caution."

Originally from my edits at https://askubuntu.com/review/suggested-edits/1167854 & https://askubuntu.com/review/suggested-edits/1168074, which the first was predictably not approved because I said "Snapcraftiness" to describe the terroristic craftiness and corruption of the auto-update mechanism. (We went from the deservedly-loved apt-get to snap/snapcraft and it could have been called "snapt" instead to pay homage, somebody thought the ever-so-witty "snapcraft" was a better descriptor so I think my wording Snapcraftiness is accurately best fitting and appropriate coding.

I've used a computer for 25 years and the first year I ever had an program problem was from installing Snapcraft.io and finding it upgrading software which did not lead to any improvement and caused actual degredation in service that the service provider denies in face of loads of user evidence. One day I found that was deeper than a bug, and nearly a hack, fully not standardized officially, describable as an inherent risk to normal/regular users.

These kinds of risks are known to corrupt data, corrupt hard drives, even corrupt entire data center servers when multiple data operations are committed to the same data points, it becomes a physical issue where there is overlapping activity which can ruin physical data storage, if not just cause software data corruption issues, sometimes known as "race conditions" (https://en.wikipedia.org/wiki/Race_condition, https://simple.wikipedia.org/wiki/Race_condition, https://stackoverflow.com/questions/34510/what-is-a-race-condition) in the programmer community similarly, if not watched carefully.

I speak from personal experience having these issues occur, and having read others experiences dealing with the aftermath of the ignorant way some software/repositories is/are blatently run not keeping these risked users in mind.