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

I see. Figured it was more complicated right after replying.

Just an idea: why not mounting the home area at its original place inside the container? I understand that it may clash with another directory already present on image, but you could deal with these cases, instead of trying a universal solution. I fully understand that an elegant, “all cases” solution is the way to go, but implementing some kind of “pre check” for clashes before launching the snap would suffice for most cases, don’t? If somebody places its home in a completely awkward path, they would’ve problems much earlier than launching snaps.

Anyway, thanks for you time. Will keep an eye on this, see if it is eventually solved.

We cannot easily create new directories inside the runtime environment. The runtime is the base snap designated by the snap developer or, as a fallback, the core snap.

The core snap has the /home and the /root directory so we can easily bind mount those. It doesn’t have the “arbitrary value stored in gecos (/etc/passwd)

I think the idea with mounting arbitrary HOME of a specific user to /var/home/LOGNAME is workable but it is complex and has some UX consequences. Another question is how to introduce that without breaking users. Perhaps only for values of HOME outside of /home or /root

That’s why I suggested mounting it at its original place. I made some experiments some time ago, using Docker to do exactly this: launch applications. I’ve solved some of these problems by using a custom entrypoint, that would make some adjustments (in this case, creating the custom home dir, if doable, e.g.), and then calling an standard exec script, that would launch the real application. Just another idea…

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,

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

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.

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.


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!


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.