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

snapd
6

Yes, I did run apparmor_parser as follows:

% sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/*
% sudo apparmor_parser -r /etc/apparmor.d/*snap-confine*
% ls /var/lib/snapd/apparmor/profiles/*
/var/lib/snapd/apparmor/profiles/snap.core.hook.configure  /var/lib/snapd/apparmor/profiles/snap.hello.universe
/var/lib/snapd/apparmor/profiles/snap.hello.hello
% ls /etc/apparmor.d/*snap-confine*
/etc/apparmor.d/snap.core.3604.usr.lib.snapd.snap-confine  /etc/apparmor.d/usr.lib.snapd.snap-confine.real
/etc/apparmor.d/snap.core.3748.usr.lib.snapd.snap-confine

And sadly, I still get:

% snap run hello
cannot create user data directory: /data1/home/hideo-t/snap/hello/20: Read-only file system

And the snap version:

% snap --version
snap    2.30
snapd   2.30
series  16
ubuntu  16.04
kernel  4.10.0-42-generic

jounalctl output is as follows (no log entry around time of error):

% date
Thu Jan  4 00:18:10 JST 2018
% snap run hello
cannot create user data directory: /data1/home/hideo-t/snap/hello/20: Read-only file system
% sudo journalctl | grep audit | tail
Jan 04 00:14:57 seventeen audit[31356]: AVC apparmor="STATUS" operation="profile_replace" profile="unconfined" name="/usr/lib/snapd/snap-confine//mount-namespace-capture-helper" pid=31356 comm="apparmor_parser"
Jan 04 00:14:57 seventeen audit[31356]: AVC apparmor="STATUS" operation="profile_replace" profile="unconfined" name="/usr/lib/snapd/snap-confine//snap_update_ns" pid=31356 comm="apparmor_parser"
Jan 04 00:14:57 seventeen audit[31354]: AVC apparmor="STATUS" operation="profile_replace" profile="unconfined" name="/snap/core/3604/usr/lib/snapd/snap-confine" pid=31354 comm="apparmor_parser"
Jan 04 00:14:57 seventeen kernel: audit: type=1400 audit(1514992497.339:53): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="/usr/lib/snapd/snap-confine//mount-namespace-capture-helper" pid=31356 comm="apparmor_parser"
Jan 04 00:14:57 seventeen kernel: audit: type=1400 audit(1514992497.339:54): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="/usr/lib/snapd/snap-confine//snap_update_ns" pid=31356 comm="apparmor_parser"
Jan 04 00:14:57 seventeen kernel: audit: type=1400 audit(1514992497.339:55): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="/snap/core/3604/usr/lib/snapd/snap-confine" pid=31354 comm="apparmor_parser"
Jan 04 00:14:57 seventeen audit[31354]: AVC apparmor="STATUS" operation="profile_replace" profile="unconfined" name="/snap/core/3604/usr/lib/snapd/snap-confine//mount-namespace-capture-helper" pid=31354 comm="apparmor_parser"
Jan 04 00:14:57 seventeen audit[31354]: AVC apparmor="STATUS" operation="profile_replace" profile="unconfined" name="/snap/core/3604/usr/lib/snapd/snap-confine//snap_update_ns" pid=31354 comm="apparmor_parser"
Jan 04 00:14:57 seventeen kernel: audit: type=1400 audit(1514992497.367:56): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="/snap/core/3604/usr/lib/snapd/snap-confine//mount-namespace-capture-helper" pid=31354 comm="apparmor_parser"
Jan 04 00:14:57 seventeen kernel: audit: type=1400 audit(1514992497.367:57): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="/snap/core/3604/usr/lib/snapd/snap-confine//snap_update_ns" pid=31354 comm="apparmor_parser"
7

Ok, there are no apparmor denials so this should indicate that snap-confine has the correct security policy. However, the “read-only” filesystem is weird. Is the filesystem mounted read-only? (this might happen if there were filesystem errors, but I suspect you would see a lot more issues than just this). Do you have other mounts that are interfering with the creation? Are the directory permissions and ownerships ok for /data1/home/hideo-t/snap/hello and /data1/home/hideo-t/snap?

8

Hmmm, I’m not seeing any mount issues.
Every directory under $HOME/snap is writable with my own uid.

% ls -la snap snap/hello snap/hello/20
snap:
total 12
drwxr-xr-x   3 hideo-t hideo-t 4096 Jan  3 23:35 .
drwxr-xr-x 102 hideo-t hideo-t 4096 Jan  4 09:30 ..
drwxr-xr-x   4 hideo-t hideo-t 4096 Jan  3 23:35 hello

snap/hello:
total 16
drwxr-xr-x 4 hideo-t hideo-t 4096 Jan  3 23:35 .
drwxr-xr-x 3 hideo-t hideo-t 4096 Jan  3 23:35 ..
drwxr-xr-x 2 hideo-t hideo-t 4096 Jan  3 23:35 20
drwxr-xr-x 2 hideo-t hideo-t 4096 Jan  3 23:35 common
lrwxrwxrwx 1 hideo-t hideo-t    2 Jan  3 23:35 current -> 20

snap/hello/20:
total 8
drwxr-xr-x 2 hideo-t hideo-t 4096 Jan  3 23:35 .
drwxr-xr-x 4 hideo-t hideo-t 4096 Jan  3 23:35 ..

% mount|grep 'snap\|data1'
/var/lib/snapd/snaps/core_3604.snap on /snap/core/3604 type squashfs (ro,nodev,relatime)
/var/lib/snapd/snaps/core_3748.snap on /snap/core/3748 type squashfs (ro,nodev,relatime)
/dev/sdb2 on /data1 type ext4 (rw,nosuid,nodev,relatime,data=ordered)
/var/lib/snapd/snaps/hello_20.snap on /snap/hello/20 type squashfs (ro,nodev,relatime)
tmpfs on /run/snapd/ns type tmpfs (rw,nosuid,noexec,relatime,size=3286976k,mode=755)
nsfs on /run/snapd/ns/hello.mnt type nsfs (rw)

Are there any other logs or config files I should check?

9

I suspect you’d need to update more than just the AppArmor rule to get snap-confine working. The C code is explicitly bind mounting /home, so it won’t see the tunable.

1 Like
10

If it is not an intended scenario, it’s not a bug.
Should I submit a feature request or something?

11

I think the reason is that snap-confine contains hard-coded logic that bind mounts /home into the execution environment. We could take the more generalized @{HOMEDIRS}/ rule but we would not automatically bind mount, for example /foo/bar.

12

Right, I forgot about that aspect of this and you and @jamesh are right. I did this successfully on a system, but that system happened to have a symlink from /home to /other/location, so it (accidentally) worked with my suggested changes. I think the logic that would detect if we should modify @{HOMEDIRS} would also need to flag snap-confine to mount that alternate directory.

At this point, the only course of action would be to bind mount /foo/bar on /home, as @zyga-snapd suggested elsewhere.

2 Likes
13

I tried the bind mount approach as suggested, and it worked fine as expected.

I’ll try out for a while to see if my existing settings don’t break too bad.

Thanks!

1 Like
14

Would someone be able to summarize what to do exactly? I am having the same issue, followed @jdstrand’s steps but I am still having the same problem.

@hideo67 Did you successfully fix the problem?

Thanks!

15

The idea suggested is to bind mount the home directory currently elsewhere under /home so that snaps can find it in the usual place.

We can eventually support other home locations, but that’s not a high priority at the moment since it’s infrequently necessary and easy to workaround with a bind mount.

16

Hi,

I used a bind mount, and changed /etc/passwd to relocate my home directory to its usual place.

It was easy to make snap work, the cost I had to pay was reconfigure a bunch of CMake C++ projects source directories that were inside my home directory. It took a couple of hours, but was bearable for me.

17

This worked for me.

snap 2.32.9+18.04
snapd 2.32.9+18.04
series 16
ubuntu 18.04
kernel 4.15.0-22-generic

App: Mattermost and onlyofficedesktopeditors

Thanks.

18

@hideo67 please explain clearly. Stucked with same issue. It will be helpful for me. Thanks in advance

19

Hi there,

I tried all this, but Snap is still telling

cannot create user data directory: /media/daten/home/robert/snap/spotify/16: Permission denied

What to do know?

 snap --version
snap    2.34.3
snapd   2.34.3
series  16
ubuntu  18.04
kernel  4.15.0-32-generic
20

Hi. Here is what you need to do.

Your home directory must actually be /home/$USER
You need to do whatever necessary to make your home directory located in that place.

I used to have my home directory on a place /data1/home/hideo.
I done that to use a second SSD drive with bigger free space.
I made that directory look like /home/hideo to the operating system.

Here is what I did:

Step 1. I added the following line on /etc/fstab

/data1/home /home none bind

This will cause a “bind mount”.

After a reboot, my home directory is visible in 2 locations, the original /data1/home/hideo and /home/hideo

Now, I need to actually make my home directory to be /home/hideo.

Step 2. For that, I edited /etc/passwd and searched for my entry, changed the home directory location from /data1/home/hideo to /home/hideo

Then, logout and login again. Now my home directory is /home/hideo.

And snap works.

I had a bunch of files in my home directory that contained absolute path names within that home directory.
I deleted them all and recreated them.

To conclude, as far as I know, you cannot keep your home directory at someplace other than /home/$USER. You have to actually move your home directory location to the standard place.

Hope this is clear enough.

Cheers.

21

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:

Here are lines from fstab:

UUID=465bfd74-ce84-4fbe-9af4-8b2d88768352 /mnt/files ext4 defaults
/mnt/files/bionic/home/user /home/user none bind

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

Any ideas on how to fix?

22

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

1 Like
23

Any update on plans to resolve this?

24

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;

  1. 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.
  2. 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.

Thanks!

25

Not with that attitude you can’t! :smiley:

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.

1 Like