Symlinked $HOME break snaps Ubuntu 20.04 (Solved)

mkdir /home/old.home
mv ~/* /home/old.home
mv ~/.* /home/old.home
ln -s /home/old.home /home/$USER
heroku login


cannot create user data directory: /home/jmunsch/snap/heroku/4048: Not a directory
ll /home/
total 24K
drwxr-xr-x 15 jmunsch jmunsch 4.0K Jun 12 01:52 .gvm/
lrwxrwxrwx  1 root    root      52 Jun 12 01:28 jmunsch -> /media/jmunsch/27df6b66-4822-4d4e-a03e-41621291ff37//
drwx------  5 jmunsch jmunsch 4.0K Jun 12 01:39 .local/
drwxr-xr-x  8 jmunsch jmunsch 4.0K Jun 12 01:50 .npm/
drwxr-xr-x  8 jmunsch jmunsch 4.0K Jun 12 01:51 .nvm/
drwxrwxr-x 13 jmunsch jmunsch 4.0K Jun 12 01:43 .pyenv/
drwxrwxr-x 26 jmunsch jmunsch 4.0K Jun 12 01:41 .steam/
sudo apparmor_status | grep heroku

12 profiles are in complain mode.


I tried:

sudo dpkg-reconfigure apparmor

# and enter /home/.snap/
  • 1620771/comments/6
cat /etc/apparmor.d/tunables/home.d/ubuntu 
# This file is auto-generated. It is recommended you update it using:
# $ sudo dpkg-reconfigure apparmor
# The following is a space-separated list of where additional user home
# directories are stored, each must have a trailing '/'. Directories added
# here are appended to @{HOMEDIRS}.  See tunables/home for details.

Ah, okay, just tried this 1620771/comments/7:

sudo rm -f /etc/apparmor.d/cache/* /var/cache/apparmor/snap.*
sudo reboot

Still didn’t work. (also tried /media/jmunsch/27df6b66-4822-4d4e-a03e-41621291ff37/)

Oof, that entire thread is a dumpster fire. :sob:

anyways :

mkdir /home/$USER
sudo mount --bind \
/media/$USER/27df6b66-4822-4d4e-a03e-41621291ff37/ \

seemed to work

so doing this in the fstab … was a complete disaster … I ran into 2 issues when trying to get the bind mount setup in fstab:

  1. login logout loop
  2. systemd-boot completely failing to a black screeen with a blinking cursor


/dev/mmcblk0p1: `UUID="27df6b66-4822-4d4e-a03e-41621291ff37"` TYPE="ext4" PARTUUID="62d71261-01"

this caused the login logout loop like logs out immediately

echo 'UUID="27df6b66-4822-4d4e-a03e-41621291ff37" /home/jmunsch ext4 bind | sudo tee -a /etc/fstab

so i was logged out immediately so logging into a tty ctl+alt+F2 I was NOT able to see the /media/jmunsch/my-home-dir so i though wow maybe i can define a dependency like github com/systemd/systemd/commit/3519d230c8bafe834b2dac26ace49fcfba139823 where “x-systemd.requires” can define mount dependencies …

this caused a total gui boot failure (boot logs, and then white blinky cursor of doom)

echo 'UUID="27df6b66-4822-4d4e-a03e-41621291ff37" /home/jmunsch x-systemd.requires=/media/jmunsch,ext4 bind | sudo tee -a /etc/fstab

after much trial and tribulation ( so i had to create a usb boot media on an old busted laptop with a broken touch pad, running xfce4 on ubuntu 17.10 … was able to nmtui, download an iso, and dd the image over to some scrap usb, disabling secure boot, disabling fast boot, and whatever else, was able to boot and mount the nvme drive using ahci … and eventually decrypting the drive, using cryptsetup luksOpen was able to mount the logical volume, and … hnngggggh )

I was able to “fix” the fstab back to a broken, but loading state.

Still looking into this.

Some other failed attempts:

#UUID=27df6b66-4822-4d4e-a03e-41621291ff37 /home/jmunsch ext4 bind,users,errors=remount-ro,nobootwait,auto 0 0
#UUID=27df6b66-4822-4d4e-a03e-41621291ff37 /home/jmunsch ext4 comment=x-gvfs-show,users,uid=1000,nofail,nobootwait,auto 0 0


sudo systemctl status home-jmunsch.mount

● home-jmunsch.mount - /home/jmunsch
     Loaded: loaded (/etc/fstab; generated)
     Active: active (mounted) since Mon 2021-06-14 23:20:21 CDT; 9min ago
      Where: /home/jmunsch
       What: /dev/mmcblk0p1
       Docs: man:fstab(5)
      Tasks: 0 (limit: 38221)
     Memory: 84.0K
     CGroup: /system.slice/home-jmunsch.mount

Jun 14 23:20:21 pop-os systemd[1]: Mounting /home/jmunsch...
Jun 14 23:20:21 pop-os systemd[1]: Mounted /home/jmunsch.

Appears to be working fstab entry, ( i’m not sure why bind didn’t work, and just defaults appears to):

UUID=27df6b66-4822-4d4e-a03e-41621291ff37 /home/jmunsch ext4 defaults

This is indeed the case, in order for you to use a /home/$USER that is not actually located at /home/$USER, it needs to be a bind mount from /home/$USER to wherever you actually want to store your home folder - symlinks specifically do not work for various reasons.

1 Like

Well… @allen-munsch it looks like you have unnecessary complicated ways to « store » your data.

You should not move /home/$USER. Nor having a separate /home partition.

Just let /home/… sits at the root of your system.

And prefer having another partition where you store what you want, mounted in a place snap is able to access :
⋅ /home
⋅ /media
⋅ /run/media
⋅ /mnt
…if a given snap app has been connected to removable-media and home interface.
see or

In /etc/fstab a bind mount will look like :

/path_to/ressource/folder/	/path_to/destination/folder	none	bind

Roughly a bind-mount is 2 folders showing the same ressource.

Example, here are my discs and partitions :

django@ASGARD:~$ lsblk -fe7 -o +size
NAME   FSTYPE LABEL     UUID                                 FSAVAIL FSUSE% MOUNTPOINT    SIZE
sda                                                                                     931,5G
└─sda1 ext4   DATA      b19322e6-8a6d-4e24-b87f-4b0155b41963  320,1G    60% /media/DATA 930,8G
sdb                                                                                     111,8G
├─sdb1 ext4   Budgie    25c341fb-320d-4a4a-9d64-b08c5fe55540    7,3G    75% /            37,3G
├─sdb2                                                                                      1K
├─sdb5 ext4   System_02 384c7fbb-8785-4c06-9053-790ad27cc3bf                             37,3G
└─sdb6 ext4   System_03 c3e7a588-524b-4a46-bbf9-cc63cdc5db28                             37,3G

my fstab :

django@ASGARD:~$ cat /etc/fstab
# /etc/fstab: static file system information.
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / [ sda1 sur ssd ]
UUID=25c341fb-320d-4a4a-9d64-b08c5fe55540	/	ext4	errors=remount-ro	0	1
UUID=b19322e6-8a6d-4e24-b87f-4b0155b41963	/media/DATA	ext4	defaults	0	2
# fichier d'échange
/swapfile                                 none            swap    sw              0       0
# vignettes .xcf et gimp snap
/home/django/.cache/thumbnails/	/home/django/snap/gimp/common/.cache/thumbnails/	none	bind

and how is organized my personal folder /home/$USER

django@ASGARD:~$ ls -l
total 4
lrwxrwxrwx 1 django django   29 avril 10  2020 Bureau -> /media/DATA/coeurnoir/Bureau/
lrwxrwxrwx 1 django django   31 avril 16  2020 Documents -> /media/DATA/coeurnoir/Documents
lrwxrwxrwx 1 django django   29 avril 10  2020 Images -> /media/DATA/coeurnoir/Images/
lrwxrwxrwx 1 django django   31 janv. 18 18:08 Logiciels -> /media/DATA/coeurnoir/Logiciels
lrwxrwxrwx 1 django django   30 avril 11  2020 Modèles -> /media/DATA/coeurnoir/Modèles
lrwxrwxrwx 1 django django   49 avril 10  2020 Musique -> '/media/DATA/Bibliothèque Musicale/Bibliothèque/'
drwxrwxr-x 7 django django 4096 mai    3 21:12 snap
lrwxrwxrwx 1 django django   39 avril 11  2020 Téléchargements -> /media/DATA/coeurnoir/Téléchargements
lrwxrwxrwx 1 django django   30 avril 10  2020 Vidéos -> /media/DATA/coeurnoir/Vidéos/

With such settings, all my snaps connected to removable-media interface do access what’s visible inside my personal folder, even if those are symlinks.

Of course it implies your $USER has correct rights and permissions to deal with the targets of symlinks.

As you can see there is one folder I did not try to move nor symlink ~/snap
This one has to stay there, in the root tree of your system, in /home/$USER

1 Like

can you explain why ? separate home partitions are usually fine as long as they are mounted correctly and in the right place … just symlinks or a mangled path for the home dir do not work by default … and for the latter case there is a config option:

To separate my own personal data, created by and for me, and store them apart in a place of my choice.

/home/$USER stays as a folder in the root system, with mostly or only .hidden folders and files for config, more or less tied to host system even if those are files and folders owned by me as $USER.

Ease managing of backups. Separate « human » data from « system » data ( in a very broad meaning ).
System can break with little to zero effect on my « human » data. Ease sharing of these « human only data » between devices and OS’es. Better performance regarding hidden config’s as the root system often sits on a faster disk than big-storage disks. Keep config files and folder « closer » to system / keep « human » data away from system.

That won’t prevent you from re-locating some config’ files and folders for some of your favorite pieces of software, web browser, mail client… { except snap ones - which sit in ~/snap so for them you may bind this ~/snap folder to your extra « human data » partition }

Or maybe even bind mount ~/snap elsewhere, I did not test that.

To make it short : yeah, it’s a /home~like~folder but without the config’ files and folders, in another location. It’s not at all a mangled path for home dir, and symlinks do work by default :

Documents -> /media/DATA/coeurnoir/Documents

no snap will complain about that ↑ granted it has been connected to removable-media interface.
/home + /home/$USER + /home/$USER/snap still sit at their most usual place, inside the root system. Only usual and visible folders inside /home/$USER have been replaced by symlinks.
Also works if you bind mount those instead of symlinks.

I had already read about AppArmor → no need in my case. And to be honest too difficult for my poor skills. I understand what I do while organizing my data this way ( it’s just a matter of partitions, mounts, rights and permissions ). I’m very far from having the same understanding about how AppArmor works.

separate home partitions are usually fine
Yes in some context they may be. One machine / few users / one OS / one or two disks.
A separate « human only data » partition is much more easier to manage in a multi users, multi OS, multi devices context.
⋅ each one of the many users has its own ( and only one ) « main » personal folder in one common known « separate from system » location
⋅ while each device keeps « at its core » the needed personal config’s, related to the OS’es it runs ( this part is important, related to the OS’es it runs ).

With a common « separate /home » across many OS’es or machines, you won’t be able to keep these things tidied up without dramatically growing the number of users in that /home and eventually numbers of symlinks to de-duplicate the data between users / machines / OS’es.

1 Like