How can I use snap when I don't use /home/$USER?

FWIW, if the embargo on snapd using overlayfs was lifted, you could easily do a mount in the rootfs wherever you wanted

/drops mic

Original place is a directory. It must exists to be mounted. I’m not sure if we are talking past each other without understanding the point each person is trying to make.

As an example. Let’s say my system has an user with HOME set to /nas/user

As that user I wish to continue using that location. Moreover I wish to to use pathnames referring to files in my home directory when interacting with snap apps.

The problem is that from an app point of view /nas does not exist. The root filesystem is an immutable, read only core snap. To mount /nas/user as /nas/user inside the “container” I need to create /nas and then /nas/user but I cannot since EROFS.

I got that. Didn’t realize the root fs was R/O. If that’s the case, then no way.

There are some ways but we cannot use them at this time. Eventually we might be able to use the overlay filesystem but at present it needs more work in the kernel to work with confinement properly.

Please try to fix this issue. Because of a simple naming, it is not ok to have many applications unusable.
Kind regards,
Ciprian

1 Like

Fedora Silverblue OSTree (31) uses “/var/home/” for $USER directroryes by default preventing to run snap applications.

Is there any workaround for cgroupsV2 and /home folder in this scenario ?

Trying to run first installed snap package on results in:

WARNING: cgroup v2 is not fully supported yet, proceeding with partial confinement

Sorry, home directories outside of /home are not currently supported.
See Support for non /home homedirs for details.

1 Like

+1
It’s not normal to find some software not functioning because of hard coding things that don’t have to.
Please fix this quikly.
Thanks in advance.

1 Like

+1 on this issue needing attention.

I see the debate above about allowing arbitrary home directories and the potential impact of that on the snap security model.

Is there any scope to allow for narrow individual exceptions, such as Fedora Silverblue’s use of /var/home in place of /home ?

Edit: It seems Silverblue in particular does ship with a symlink out of the box, linking /home to /var/home (the root FS is immutable and everything writable is mounted under /var).

Does the presence of this symlink make fixing the issue any easier?

I was directed here because sanp installs and snapd fail on my shiny new Ubuntu 20.04 (lasteest release).

For me and my industry experince this is a wrong turn. User facing function must always respect the user’s expressed intention in my book. This behaviour is equivalent to telling the user to make sure the compiled binary code is OK.

The semantics are straightforward: “/home/$USER/”, it is a regular Unix path name.

The flaw here lies in the over-reach to resolve perfectly legitimate human use file paths into machnine talk. When in truth use of the given (legitimate) path of “/home/$USER” will or should work in all cases. That is the design of the file system, symbolic links and mounts.

For comparison; I do not expect a compile error when the expression “i +=2;” isn’t written as “i = i+2;” And that is more or less what has happened here. A correct file path is rejected because of some internal scruples that have not bearing on usability or function.

If there’s a limitation in the stack, that needs to be fixed. So far I’ve found users are never the problem. Users want to DO something, technology’s role is to facilitate that something, not to put-up barriers. This is a very fundemental problem.

Software/Tooling must follow the user’s needs and wants.

1 Like

I ran into this problem due to using a domain account.

My HOME directory was /home/DOMAIN/matthew

After running into the same problems described in this thread, the following fixed it for me.

You need to add your additional HOME dir locations to the apparmor config which is done by running the following command.

sudo dpkg-reconfigure apparmor

I entered /home/DOMAIN/

This resolved my problem instantly.

6 Likes

sudo dpkg-reconfigure apparmor
I entered /home/DOMAIN/
This resolved my problem instantly.

This should be added to the snapd installation page!

that’s a good suggestion - I’ll add it to our troubleshooting page (Troubleshooting), and add a link to that page from the installation page. Thanks!

2 Likes

I think a normal user shouldn’t need to know this commands. this should be available by default

an admin who is able to set up his users to use /home/DOMAIN should surely be able to also run the apparmor re-configuration for his users when making the other modifications to the standard install …

1 Like

Hi, I tried the solutions provided here, bu still cannot make this work. My setup is as follows: I have multiple hosts (like a hundred, including cluster nodes), which have both local and remote users (taken from AD). Majority of the users (over 300) are the remote ones. The local users on given machine have home directory located in /home. For those snapd works perfectly. The remote users have the home directories located in /macierz/home which is mounted via NFS. Local users need to work at all times, they work perfectly with snapd. The remote users however cannot run snaps due to the permissions. The home directories cannot be easily moved to /home as they would overlap with the local users and people are already accustom to the homedir locations, multiple scripts also work based on that location. How can we use snaps with that setup? I really believe that this is a major problem and in distributed, multiuser environment you should be able to tell snapd where the home directories are.

Similar situation here. For enterprise use, it’s simply not feasible to have a Snap “confined” to home dir only; also, there’s this situation with different home directories (again, I live the same thing). I know that it’s difficult to setup AppArmor and other confinement techs to support all different scenarios, but some solution should be provided, if corporate use is, by any means, a goal of Snaps. Obviously, I’m talking about medium-sized+ companies; small ones might do just fine.

If AppArmor is the only thing blocking this, there should be a comprehensible doc telling how to reconfigure it. We could even have some config, like the ones in snap set system ....; something like snap set system homedirs, that could take a list of directories to be injected into AppArmor profiles; same thing for external directories, that could be injected into the profiles whenever they had home plug, but without dot files restriction, for instance. Well, just a shit storm, as we say here…

Fact is that this a much needed feature. I know manpower is not infinite, but maybe this could, at least, make its way into the roadmap, if it’s not.

AppArmor is the easy thing to fix and the harder part is the changes needed for snap-confine (which is why a bind mount is suggested as the workaround). I’ve suggested something similar to what you said with snap set system homedirs which would:

  • add a snippet for snap-confine’s profile to /var/lib/snapd/apparmor/snap-confine/homedirs
  • add a file to /etc/apparmor.d/tunables/home.d to modify HOMEDIRS
  • write out something for snap-confine to read to perform the necessary mount for /home into the snap’s mount namespace

OTOH, a sticking point is that snap-confine is working in the mount namespace that is shared across all snap invocations, so a mixed system with /home and /foo/homes needs to be handled (perhaps moving the home part to the per-user portion of the mount namespace? cc @zyga)

1 Like

I don’t think @zyga-snapd is monitored anymore, but @zyga is :slight_smile:

@zyga I was wondering, didn’t you consider in the past using a similar technique to the one used in layouts for read-only locations (tmpfs with empty files, which are used by bind mounts), as an alternative to overlayfs?

In other words this: statement from snapcraft.io/about:

“A snap is a bundle of an app and its dependencies that works without modification across Linux distributions.”

is a complete lie, because u have to have a sysadmin around to fix it?