I attempted to work around this issue as suggested with a bind mount line in /etc/fstab linking /home/user to a directory on a separate ext4 partition that is itself mounted at /mnt/files:
I discovered that this stops Gnome trash from being able to move any files to trash in directories on /mnt/files (Ubuntu 18.04). It will present a dialog saying the file cannot be put in the rubbish bin, and instead must be deleted immediately.
Testing with gio shows why:
gio trash /mnt/files/testfile
gio: file:///mnt/files/testfile: Unable to delete file /mnt/files/testfile across filesystem boundaries
@zyga-snapd, with all the recent changes for snap-confine and snap-update-ns, can you think of a path forward for this long-standing issue? It would be great if an admin could say something like “I have user directories in /home, /foo and /mnt/bar”. AppArmor supports this fine; we just need to not hardcode snap-confine. Thoughts?
I’ve been transitioning from Windows to Linux for years. I was really excited to learn about Snap. It sounds like a great solution to make programs more universally available. I installed it today so that I could try one of my favourite Windows editors on Linux; Notepad-plus-plus.
Imagine my disappointment when it didn’t work! Due to some issues with my motherboard not being able to boot from my big Samsung 1TB SSD, I’ve got a little bitty 128gb SSD where I installed Linux Mint. I use Dropbox to store/backup all my programs and media files. It’s huge and it wants to keep the local folder in my home folder. No space for that! no problem, I moved home to /mnt/SSD1TB/home/jgold.
It seems that snap needs the home directory to be in /home/jgold before it will work. This means that Snap doesn’t work for me at all. The solution according to this thread is to make sure your home directory is \home\jgold.
No can do!
I understand that this is a bug and it will be fixed. There are limited resources and you’re volunteers. (I appreciate all the time put into this by the way, It looks like a GREAT idea!). I’m hoping to move the priority to fix this up a little.
There are two reasons I think this should have a higher priority;
Requiring the home directory to be in a specific place is very un-linuxy. It’s looks like someone missed something really basic. It makes Snap look bad.
When someone runs into this issue, they’re basically unable to use Snap at all without making some difficult changes to their system. This is especially difficult for new users or old ignorant users such as myself.
To summarize: I really like the idea of Snap. I’d like to use it. I can’t without a whole lot of extra work that I really don’t want to do. Fixing this issue will make Snap work and look better.
Technically you likely can have /home/jgold just fine, and have it mounting some space on /mnt/SSD1TB but you chose to actually change the path to your home as well as the storage location? I appreciate that it is indeed still somewhat of an oversight / bug that we still rely on $HOME being /home/$USER but in your particular case it is actually possible to do what you’ve done and still comply with the requirements for snaps.
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?
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.
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.
