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

+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?

Dude, /home is NOT the default location and NEVER has been. Your inexperience with Linux/Unix is showing now. It may be the norm now, but I remember having to change it from /var on Irix, Solaris, SunOs… all- distros except Debian and I think RedHat since the 90s, up until Ubuntu came around, after the file system standard was MOSTLY adopted (I think RedHat still uses some variations). So be careful who you think you’re talking to.

Well - I have plenty of time now to waste while snap gets removed. Not like I have anything else to do with my life but troll round the internet trying to find why basic bits of software don’t work.

Basically I don’t know why snap needs to write anything to my home directory at all. I fixed my issue by uninstalling snap and just install my package another way. I know you think they are making things easier but the more stuff you add the more maintenance you will have.

I apologize for being negative but truth is truth. Just my own opinion.

-Robert

It’s the snaps themselves that need to write into your $HOME. AppArmor can’t give them access if it doesn’t know what folders they’re supposed to be able to access, and they can’t be mounted into the sandbox if there’s nowhere saying where that mount should be.

This has been a mostly solved problem for a few releases now, because you can actually tell snap where alternate homes are located, and it’ll adjust policies accordingly.

I remove snapd and problem solved. Have a great weekend.

Thanks, Robert Campbell

Are you aware that every single app that has persistent config options, uses any type of caching or ships with adjustable defaults actually writes to your home dir ?

Non-snaps simply hide their directories in your home from you, snaps do not, so complaining about “apps create data in my home, this is why i removed the complete packaging system for them” with a footstomp is rather ironic…