You are correct. Or you guys could just fix it so that it works correctly so that new users don’t have to waste a bunch of time figuring out why it doesn’t work when everything else on their system works fine. I wonder which option would be better? 
Thank you for your reply.
Hello. I maintain I fairly large network of Linux machines here at University of Helsinki. I have here more than a thousand users, of whom have multiple different networks shared home directories, which are chosen on login time. Some times the home directory is a also a local home directory instead of a network share. It is really up to the users to decide and not to me. The solution so far has to be to make /home/luser a symlink to where the real home is and this has been fine since symlinks were invented (after all, this is the reason they were invented). And the users need to do their jobs and shouldn’t need to care about paltry problems like this. Now, there is now software which isn’t available on deb packages anymore (heroku) and the only way this is fixable by next week is that I package heroku myself. I need to get this done by this week, so tweaking a University wide system is out of the question. This shouldn’t be something on a wishlist, this is a major showstopper.
Oops. It turns out that heroku has a perfectly adequate deb repository. Its location is just hidden inside a shell script. So, no need to build anything myself and no need make snap work for just this software. Sorry about the rant, but snaps still won’t work in this environment.
This problem is evident when using snap installed lxd on a jenkins box since jenkins home is /var/lib/jenkins by default.
As a workaround for those hitting this with Jenkins, setting JENKINS_HOME to /home/jenkins and adding an entry in fstab to mount /var/lib/jenkins to /home/jenkins did the trick.
Hey guys, do we have a timeline regarding this problem? I’ve stumbled on it, CentOS 7 (corporate environment) and can’t really apply the workaround mentioned here. I’d really like to see it solved.
I have some ideas but it’s a technical idea and I’m not sure the usability would be just right.
The technical idea is that whatever your home directory is, it would be mapped to a fixed base inside the execution environment. It could be the new /var/home that is now also used by some other systems.
Snapd could make sure that the user’s real home directory is mapped there on startup. We could further manipulate gecos data to make it appear that $HOME is /var/home/$LOGNAME - regardless of the real location.
The question is: is this discoverable? Perhaps. One advantage is that due to alignment with other systems we might just end up with this working seamlessly. If Gtk and Qt both learn to understand this concept it would be the best of solutions.
Other solutions that tweak apparmor only work to a certain degree. The principal problem is that we cannot represent arbitrary directory on the host system inside the snap execution environment, while preserving the path perfectly. If your organisation is using /nas or /home/nfs/ or /stuff or whatever else people wish to come up with, we just cannot support that with the technical limitations that we have today.
While your brain is in this mode, a related issue is that of ~/snap in the $HOME. I have heard on a number of occasions that this mandated, unchangeable directory name gets on people’s nerves. Especially those who carefully curate their home directory. I appreciate this is a separate topic, but it feels related.
We actually designed (though I don’t believe it is approved yet) a super nice solution for this issue. The main folder would go away (it would become hidden in arbitrary but constant location relative to home). The user visible portion would be something that the user can show or hide in their home folder, under any name (including a localised one). The contents of that folder would be a FUSE filesystem that shows a per-snap instance view of the relevant data. The main improvement is that it would be something that the app participates in. This would fix the current design issue that users see revision, see the common directory and each of the revisions is a mini-home directory with more dot files and other hard-to-follow things. The new filesystem would show only that subset of said that that snap developer explicitly wishes to surface. For instance a developer of a snap foo might say that $SNAP_USER_DATA/.foo/config.ini should be surfaced as config.ini. The user could then navigate to ~/Snapy/foo/ and see only the config.ini file there. Here ~/Snapy is an example localised name.
Hi @zyga-snapd, thanks for your answer. Could you please elaborate more on what are these technical limitations, if feasible?
The tl;dr; version is that snap applications and hooks execute with a root filesystem composed of a read-only squashfs. There is simply no good method of adding things there. We have a way to add some things to sub-directories but it is only applicable to certain situations (aka writable mimic in the source tree).
We are running in a foreign filesystem. We cannot hope to bring arbitrary parts of the original host filesystem over and keep apps running.
I see. To be honest, I didn’t mean to map the whole home area inside the container, but adapt snap-confine to understand user’s real home, in order to map these things you’re talking about (Documents and other directories, if I got it right). Currently, we’re unable to even start the snap.
It seems that this is a long way from being done (if done at all). Is that correct?
How about mapping /random-home-root/my-home into /home/my-home, not that it would be straightforward as $HOME when confined would need to be adapted and many other things I am not seeing right now.
Right, but where is your home? What are the limitations on that? If the home is in /stuff/nas/homes that’s sort of okay right? Because it doesn’t clash with what is inside a snap root filesystem. What about /var/lib/homes, or /usr/lib/homes. The thing is, the location is arbitrary. We cannot make the situation better by bridging a few random locations some people use. We bridge the default location, /home since all custom setups can be reduced to "whatever it is coming from, it is mounted in /home/$LOGNAME.
The technical limitation stands but apart from it, we should clearly define what are the expected locations. This has serious impact on the sandbox technology, both apparmor and SELinux, on testing and support.
I think we will only realistically support this if there’s a clean way to recognise that a given user uses a non-default home directory and that can be supported both technically (for runtime and sandbox parts) and for user experience (so that we don’t have different $HOME for snap apps and for classic apps).
Well, I think that “getent passwd {user}” can give you that (you can use OS calls, I’m just giving an example). That would solve the “where is your home” problem. As for the technical problems in using that info, I can’t say much.
Really, I’m assessing application containers techs since we’ll probably have to use this here; I’m trying to understand if this is a road-block kind of problem or a solvable one.
Getting the location of the home directory is not the problem. The problem is supporting the arbitrary response in a way that doesn’t break applications or the user experience.
I think there are some ideas to explore or go forward with but they are not perfect or seamless.
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
