Home directories outside of '/home'

doc
1

The snap daemon (snapd) looks for a user’s home directory ($HOME) under /home on the local filesystem. However, from snapd 2.59 onwards, the snap daemon can access an additional location using the homedirs system option:

sudo snap set system homedirs=<destination-directory>

This allows a snap’s user data to be stored in a user’s home location other under /home.

The following command will permit home directories to be accessible from /remote/users, for instance:

$ sudo snap set system homedirs=/remote/users

The new location needs to exist and be accessible, but it can be on a different filesystem or even mounted across a network. The original /home location remains valid but it is no longer a requirement that directories be stored there.

Once set, the homedirs system option can be retrieved with the snap get command:

$ sudo snap get system homedirs
/remote/users

The homedirs value can be cleared and restored to only /home with the snap unset command:

sudo snap unset system homedirs

Bind mount home directories

While the homedirs system option should work for the majority users, it’s also possible to bind mount an alternative $HOME location to /home to allow other locations to be found by snapd. This process is outlined below.

:information_source: A bind mount allows a mounted filesystem to be accessible from more than one location at the filesystem level. This is unlike a hard or symbolic link, for instance, which operate as special additional files that point to a destination.

There are two steps to bind mount a home directory to a different location:

  1. the bind mount: create the mount point and run the mount command:
    $ sudo mkdir -p /home/$USER
$ sudo mount --bind <original-home-location> /home/$USER
  2. edit /etc/passwd: backup passwd and edit the home location for your user:
    $ cp /etc/passwd passwd.backup
$ # sudo edit /etc/passwd with your favourite editor
$ cat /etc/passwd | grep $USER
  ubuntu:x:1000:1000:ubuntu,,,:/home/ubuntu:/bin/bash
    The following awk command can be used to edit /etc/passwd (change OLD_HOME to your old home directory):
    $ awk -vold=$"OLD_HOME" -vnew=$"/home/$USER" -F: ' BEGIN {OFS = ":"} \
  {sub(old,new,$6);print}' /etc/passwd > passwd.new
$ sudo cp passwd.new /etc/passwd

Log out and back in again, and snap will work from the freshly mounted home location. If you run into difficulties, copy the backup passwd file to /etc/passwd.

2 Likes
2

This helped me on CentOS 7, but it did require a small modification. The provided awk command replaced the passwd entry with just “/home” instead of “/home/username”, which prevented me from logging in.

I had to manually update the passwd file to use /home/username, and after that it worked as expected.

3

If /home is used by automounter (nfs) for ldap users it is not possible to add a bind mount to /home for local users.

4

@prattm is right. The awk command is slightly wrong. The new home path needs to be fully specified. For example for the nagios user see the following example.

$ awk -vold=$"OLD_HOME" -vnew=$"/home/$USER" -F: ' BEGIN {OFS = ":"} \
  {sub(old,new,$6);print}' /etc/passwd > passwd.new

I tried to edit the original post as well.

2 Likes
5

Question: Is the solution outlined on the following website (dpkg-reconfigure apparmor) a promising alternative, or is the information given there outdated?

To me, this looks simpler, but I’m still hesistant to try either solution.

1 Like
6

Hi

The solution here assumes that your user is on the /etc/passwd file. But on my case, my users come from Active Directory, so, they are not there. I’m using sssd and I figured out that our IT sets the home directories to be in: /nas, so, a user “doe” will have /nas/doe@DOMAIN as home directory.

I tried the binding option, but since my user isn’t on the passwd file, I couldn’t edit it as suggested here. Only binding didn’t worked. Setting the HOME variable to /home doesn’t works either.

At the end what worked for me was adding this option:

override_homedir = /home

To the file: /etc/sssd/sssd.conf, then you have to restart sssd:

service sssd restart

Then all snaps packages will start normally.

Don’t forget to delete your user’s old home directory before login back.

Best regards Josef

7

@degville

With snapd 2.59 it’s now supported to configure additional home directories outside of /home using the snapd setting

snap set system homedirs=...

Say you have home directories at /remote/users, then you would configure this additional home directory to

snap set system homedirs=/remote/users

This would then make sure that the homedir is available to the snaps.

2 Likes
8

That’s a fantastic update, thanks for the heads-up. I’ve updated the doc, and also added homedirs as a new system option.

9

@degville This sentence and the one directly below seem to be cut short.

10

Hello! Fantastic to hear from you - and thanks so much for flagging this. I’ve now fixed it.

1 Like
11

Does this mean it replaces your /home as something else? What if it’s just an additional directory for your data?

trying to get rid of this error:

Jul 27 16:32:05 audit[154085]: AVC apparmor="DENIED" operation="open" class="file" profile="snap.armcord.armcord" name="/media/DATA/WDB4TB/yamiyuki/Downloads/" pid=154085 comm="head" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
Jul 27 16:32:05 audit[154090]: AVC apparmor="DENIED" operation="rmdir" class="file" profile="snap.armcord.armcord" name="/media/DATA/WDB4TB/yamiyuki/Downloads/" pid=154090 comm="rmdir" requested_mask="d" denied_mask="d" fsuid=1000 ouid=1000

> sudo journalctl -f | grep -e bitwarden                 
Jun 08 19:09:58 Y4M1-II systemd[4441]: Started snap.bitwarden.bitwarden-2ae4b4b7-2663-44e2-8edd-797af60a4a53.scope.
Jun 08 19:09:58 Y4M1-II audit[2186979]: AVC apparmor="DENIED" operation="open" class="file" profile="snap.bitwarden.bitwarden" name="/media/DATA/WDB4TB/yamiyuki/Documents/" pid=2186979 comm="head" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
Jun 08 19:09:58 Y4M1-II audit[2186982]: AVC apparmor="DENIED" operation="rmdir" class="file" profile="snap.bitwarden.bitwarden" name="/media/DATA/WDB4TB/yamiyuki/Documents/" pid=2186982 comm="rmdir" requested_mask="d" denied_mask="d" fsuid=1000 ouid=1000
12

Does connecting the snap to the removable-media interface resolve the access problem?

13

Armcord doesn’t have it, and I can’t recall if Bitwarden does.

I am pretty sure I would’ve checked and enabled them.

14

I got it to launch.

I created a bind mount for the disks in /media/DATA to /home/DATA.

I moved it to /media/DATA originally because Steam Snap doesn’t seem to like it if I mount it in /home/DATA, but the inverse is also true for apps like Armcord and Bitwarden.

My fstab entry has this note LOL:

## Bind to bypass Snap AppArmor
/media/DATA     /home/DATA      none    rbind,nofail    0       0
1 Like
15

Question as I’m looking for something definitive here: what’s supposed to be the definite location for non-home directories where we can mount our internal drives, especially for snaps that don’t have a removable-media interface if they don’t need it.

I have 3 internal SSDs + 2 internal HDDs.

My primary NVME is currently both my root and my home, and my other internal drives internal drives

# Samsung 870 EVO 4TB
UUID=0bb8935f-39aa-4abc-82ec-615c62241aed   /media/DATA/870E4TB         btrfs   defaults,subvol=@data,space_cache=v2,compress=zstd            0 2
UUID=0bb8935f-39aa-4abc-82ec-615c62241aed   /media/vm/870E4TB           btrfs   defaults,subvol=@vm,space_cache=v2,compress=zstd              0 0

#WD Black 8TB
UUID=e7cf9d14-a7f1-45df-b28e-431dcd78c9d2   /media/DATA/WDB8TB    btrfs   defaults,subvol=@data,noatime,autodefrag       0 2

## WD Black 4TB
#UUID=83811a58-3303-4f51-8732-66984fa8737c   /home/DATA/WDB4TB          btrfs   defaults       0 2 
UUID=83811a58-3303-4f51-8732-66984fa8737c   /media/DATA/shared/data     btrfs   defaults,subvol=@shared-data,space_cache=v2,compress=zstd,noatime,autodefrag      0 0
UUID=83811a58-3303-4f51-8732-66984fa8737c   /media/DATA/WDB4TB          btrfs   defaults,subvol=@data,space_cache=v2,compress=zstd,noatime,autodefrag         0 2

## SanDisk Ultra3D 4TB
UUID=8082fea5-a028-4414-b12b-48daf2dc5b78   /media/DATA/U3D4TB          btrfs   defaults,subvol=@data,space_cache=v2,compress=zstd            0 2
UUID=8082fea5-a028-4414-b12b-48daf2dc5b78   /media/DATA/shared/games    btrfs   defaults,subvol=@shared-games,space_cache=v2,compress=zstd      0 0
UUID=8082fea5-a028-4414-b12b-48daf2dc5b78   /media/DATA/shared/apps     btrfs   defaults,subvol=@shared-apps,space_cache=v2,compress=zstd       0 0
UUID=8082fea5-a028-4414-b12b-48daf2dc5b78   /media/vm/U3D4TB            btrfs   defaults,subvol=@vm,space_cache=v2,compress=zstd              0 0

## Bind to bypass Snap AppArmor
/media/DATA     /home/DATA      none    rbind,nofail    0       0

I understand that /media was supposed to be just for temporary data, so I’m planning on moving it to /mnt just to clean it up (and its sorta been bothering me that it’s not standard). /home/DATA trick that I did doesn’t even work on some apps, like Steam and Musicpod. The latter, I just discovered, and I figured I should setup my system in a definitive way, since the only way my music got loaded is with the removable-mount enabled and using the one in /media/DATA instead of /home/DATA.

The link from @cohomology84 got me digging and found these:

> ls -l /etc/apparmor.d/tunables/home.d/*
-rw-r--r-- 1 root root 634 Jun  5  2023 /etc/apparmor.d/tunables/home.d/site.local
-rw-r--r-- 1 root root 337 Jun  4 07:29 /etc/apparmor.d/tunables/home.d/ubuntu

> cat /etc/apparmor.d/tunables/home.d/*         
# ------------------------------------------------------------------
#
#    Copyright (C) 2010 Canonical Ltd.
#    This program is free software; you can redistribute it and/or
#    modify it under the terms of version 2 of the GNU General Public
#    License published by the Free Software Foundation.
#
# ------------------------------------------------------------------

# 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. Eg:
#@{HOMEDIRS}+=/srv/nfs/home/ /mnt/home/
# 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.
#@{HOMEDIRS}+=

If I wanna be mounting my internal drives without needing to keep adding HOMEDIRS, do I put it in /mnt/home, and create directories for mounting, similar to what I’ve been doing now where I created internal mounts inside /media/DATA or /home/DATA? Or do I just keep adding separate homes for each drive?

and with the command sudo snap set system homedirs=/remote/users, how would I add multiple directories?

16

and with the command sudo snap set system homedirs=/remote/users , how would I add multiple directories?

Comma-separated list is the way to supply multiple homedirs here.

1 Like
17

Did something break with this feature?

My Bitwarden snap stopped opening and it was throwing an AppArmor error saying it can’t read my Documents directory in /mnt/home/870E4TB/yamiyuki/Documents.

My homedirs variable is set to the entire /mnt/home. It was working fine until 2 days ago.

I’ll get the logs and the config later as I’m currently out.

Edit

Not sure if this should be disregarded, but it seems it’s not playing well with Security Center atm

18

Related issues in the desktop-security-center repo (thank you for opening these):

1 Like