I've solved my snap challenges problems with the following state entry
in Saltstack
cleanup_snapd:
pkg.purged:
- name: snapd
pkg.held:
- name: snapd
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Hello, we have NFS homes with no_root_squash, and none of the previous
solutions work. There is still the error "snap-store_snap-
store.desktop[106283]: cannot open path of the current working
directory: Permission denied" when we want to run the Snap Store so that
users can install applications.
We did some progress in investigating this, and it appears that a
problem still exists: if the system is using autofs and snapd is started
before any NFS home directory is mounted, snapd will fail to detect the
fact that the system is using autofs (or NFS), and will not grant snap-
confine those
Same problem here, with 22.04 and firefox :
https://forum.snapcraft.io/t/cannot-open-path-of-the-current-working-
directory-permission-denied-bis/28704
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
@acubuntuone we don't use kerberos authentication for NFS mounts here,
and I face the same problem.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1662552
Title:
snaps don't work with NFS home
To
I am pretty sure this is at least partly a problem with snaps not
working with Kerberos, which is the authentication mechanism for NFS.
The Kerberos credentials are (with good reason) not stored in the home
directory.
I described this in more detail in bug 1784774.
This means that firefox and
This still doesn't work with 22.04, which is a problem for firefox,
which is now installed as a snap. This seems somewhat strange as firefox
obviously needs network access, so it is not just the network access
that causes problems.
Running firefox from the command line produces an error
I should add that at the moment, my first problem is still that NFS
seems not permitted at all:
$ aptitude show snapd
Package: snapd
Version: 2.47.1+20.04
State: installed
# snap install pdftk
2020-10-26T15:12:47Z INFO Waiting for automatic snapd restart...
pdftk 2.02-4 from
Hey Markus.
Thank you for providing details about your environment. Unfortunately we
don't have any new ideas on how to solve home-at-nearly arbitrary path
and we certainly didn't have time to push this idea forward.
One idea I had a while ago is to mount whatever the original location of
HOME,
Having briefly tried to get snap to work a few years ago on Ubuntu
18.04, before giving up, I have just upgraded to Ubuntu 20.04, and snap
appears to cause problems again, especially as larger parts of Ubuntu
now seem to rely on snap (e.g. the "Software Install" GUI tool).
Therefore I'm interested
@Marc, what is the bug report you've opened?
Chromium has no more debian packages as the team supporting it decided
that it is exceedingly difficult to maintain (especially for releases
other than latest). This is unrelated to snapd. Without snapd it would
simply be removed from the archive.
--
Yes, I also removed snapd on all machines in the office, because it was
a total unstable mess in 18.04 and reinstalled the Gnome calculator and
some other apps that had been switched to snaps by default via a method
that actually works everywhere.
Unfortunately the chromium package from the
Marc Kolly, could you please open a new bug with details of your
particular configuration please. Commenting on a bug that is fix
released is not useful as we have integration tests that verify this
particular particular behavior works. I suspect there is something about
your setup we are
My solution has been to fully remove all snap functionality.
sudo apt purge snapd
sudo rm -vrf /snap /var/snap /var/lib/snapd /var/cache/snapd /usr/lib/snapd
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Hello all,
we have since then upgraded all our machines to Ubuntu 20.04 and are
facing the same issues here with our NFS4 homes.
I moved the mountpoint from /user to /home as @zyga suggested, but had
no success actually running snaps.
Oct 05 15:55:20 pc-021 systemd[1583]: Started Application
I think I've discovered a different wrinkle to this issue that I haven't
seen discussed here.
There are, in my experience with trying to work around this, three
separate issues.
1. It's necessary to add the root of your NFS home directories to
{@HOMEDIRS}. I have done that, and confirmed that
Hello
Please forgive me this brief answer. Snaps require user home directories
mounted at /home. Using /user regardless of NFS is not supported. I
believe another bug tracks that issue
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
I recently reinstalled around 20 fat-clients to Ubuntu 18.04, which were
previously running 14.04 and I am running into the same problem.
Just like michalmaria, our configuration is:
1. Debian 10, provides home folders via NFS and runs Kerberos, OpenLDAP is
off-site.
2. Ubuntu 18.04 clients.
May I add that snap is not working on HOMEs which have symlinks in path
(ie: ln -fs /local/home/user /home/user)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1662552
Title:
snaps don't work with
Sorry guys for not responding to your questions. I somehow didn't get
the notifications about the discussion here. Also: I didn't really look
further into this, because of a simple workaround I had to implement:
remove all snap apps and install them from the repos.
Now I did recently upgrade all
I'm finding that when vlc is installed via snap, it's unable to play a
file that is NFS automounted. Fixes that target only /home are missing
the point. Is there a more general workaround or fix that addresses
Markus Kuhn's and Andrew Conway's observations above?
--
You received this bug
The real bug here is that AppArmor should restrict NFS access only via
the file-path rules, and not via the network rules, since if an
application accesses a file via NFS, all related network traffic is
initiated and controlled by the kernel (or by kernel helper processes
like automount, rpc.gssd
I have the same problem. The fix does not help. I use autofs to mount
particular users rather than all of /home, which I think the fix
requires. Someone else doing the same thing as me opened a new bug
1782873 with details of setup, but I think the issue is the autofs
rather than boot mounting of
Hello jdkelleher.
Can you please provide more details about your setup? Things like "snap
version" output, the location of the NFS mount, the snap you used,
"dmesg | grep DENIED" output when you tried.
Ideally please open a new bug to scope the conversation there.
--
You received this bug
The issue appears larger than just NFS mounted $HOME.
After I used the workaround provided to get the filebot snap to run with
an NFS mounted $HOME, I was unable to use it to manipulate any files in
my NFS mounted media library.
I gave up and just loaded the deb package.
Should this be reported
Michal Kukuča, we have a test case but it may be missing something that
is evidently going on in your use case. I will review the code, the
denial and get back to you shortly.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Michal, can you please list the contents of this directory:
/var/lib/snapd/apparmor/snap-confine
In addition, can you please provide the fstab entry that mounts the NFS
share?
I'm trying to understand if our NFS detection logic is kicking in
--
You received this bug notification because you
Michal, have you done the things described in
https://forum.snapcraft.io/t/snaps-and-nfs-home/438 ?
On Mon, 14 May 2018 at 14:46, Michal Kukuča <1662...@bugs.launchpad.net>
wrote:
> With Ubuntu Bionic 18.04, snapd version 2.32, Snap still doesn’t work
> correctly with home folders mounted via
With Ubuntu Bionic 18.04, snapd version 2.32, Snap still doesn’t work
correctly with home folders mounted via NFS. I’m even unable to use
basic applications like System monitor:
kernel: nfs: RPC call returned error 13
kernel: audit: type=1400 audit(1526303580.147:309): apparmor=“DENIED”
This has been released for a while now. Please reopen if there are more
issues.
Note that /home/$anything cannot be a symbolic link. Please use a bind
mount if necessary (this is a separate issue).
** Changed in: snapd
Status: Fix Committed => Fix Released
** Changed in: snapd (Ubuntu)
@ogra Ah, thanks for the info.
@zyga Switched to the beta channel, but still not working :-(
1 torkel@matilda:~⟫ hello-world
cannot perform operation: mount --rbind /home /tmp/snap.rootfs_EilQKW//home:
Permission denied
Nov 5 00:52:36 matilda kernel: [119451.849036] audit: type=1400
just a FYI. all snapd development happens focused on the last LTS
(xenial) and fixes are either forward or backward ported to the other
supported releases ... so xenial indeed gets it first in any case (thats
true for all snapd fixes (at least until the next LTS comes around))
--
You received
Yes, this will be available in Xenial when 2.29 is released to stable.
If you switch the core snap to the "beta" channel with "snap refresh
--beta core" you can get advantage of this straight away.
On Mon, Oct 30, 2017 at 12:42 AM, Björn Torkelsson
<1662...@bugs.launchpad.net> wrote:
> Any change
Any change that this will be fixed in/backported to Xenail?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1662552
Title:
snaps don't work with NFS home
To manage notifications about this bug go
It's in master now.
** Changed in: snapd
Status: In Progress => Fix Committed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1662552
Title:
snaps don't work with NFS home
To manage
This is now under review at https://github.com/snapcore/snapd/pull/3958
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1662552
Title:
snaps don't work with NFS home
To manage notifications about
I have implemented a proof of concept and got initial round of feedback
from the team. I will address the mentioned issues, add some more tests
and propose a PR for evaluation.
** Changed in: snapd
Assignee: (unassigned) => Zygmunt Krynicki (zyga)
** Changed in: snapd
Status: Triaged
I'm working on a workaround for this. I have some initial patches that
change the policy for snap-confine and other snaps and I'll propose them
as soon as I can write some spread tests to ensure this works.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
There is also the case of snaps with classic confinement, which exhibit
the same behavior as described here:
https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1713767
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
I've also updated https://forum.snapcraft.io/t/snaps-and-nfs-home/438/8
for additional implementation details. I believe there is enough there
for someone to pick up the work. While this is on the snapd team's
radar, it is currently not prioritized. If someone wants to implement a
fix for this
The workaround is brittle with newer snapds since if the core snap is
newer than the installed snapd, the profile for snap-confine from the
core snap is used. This profile is on read-only media. The
/etc/apparmor.d/usr.lib.snapd.snap-confine.real is the profile these
days for the snap-confine on
Any news on this bug (for 16.04)?
Unfortunately the workaround does not work for me.
In my case /home is a link to /import/home (i.e home is autofs mounted),
so I guess my problem is also related to #1620771?
Btw, I assume that /etc/apparmor.d/usr.lib.snapd.snap-confine in the
workaround should
FYI, https://forum.snapcraft.io/t/snaps-and-nfs-home/438
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1662552
Title:
snaps don't work with NFS home
To manage notifications about this bug go to:
** Also affects: snappy
Importance: Undecided
Status: New
** Project changed: snappy => snapd
** Changed in: snapd
Status: New => Triaged
** Changed in: snapd
Importance: Undecided => Medium
--
You received this bug notification because you are a member of Ubuntu
Bugs,
Thanks for the workaround.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1662552
Title:
snaps don't work with NFS home
To manage notifications about this bug go to:
** Description changed:
+ Strictly confined snap commands that don't use networking in their
+ interfaces (eg, 'plugs: [ network ]') do not work for users with NFS
+ home because of AppArmor denials for networking.
+
+ WORKAROUND:
+ Add the following to /etc/apparmor.d/abstractions/base and
Robert, your comment "Enabling network access for all snaps just to make
them compatible with NFS don't seems to be a perfect solution from the
security perspective" is exactly right. It is not possible (currently)
to only allow networking for NFS. This may be possible at some point in
the future
Will there be an Update of the installation package? Will the lines
#include
#include
be included?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1662552
Title:
snaps don't work with NFS home
On Fri, Feb 10, 2017 at 08:15:42AM -, Robert Redl wrote:
> 2. Including #include directly below
> /usr/lib/snapd/snap-confine flags=(attach_disconnected) works. It don't
> seems to be necessary to include #include
You may have trouble killing the processes running in this domain from
1. I already had @{HOMEDIRS}+=/home/*/ and I did not forget to reload.
However, the audit message still refers to /home/r/, which is the actual
parent directory of my home directory.
2. Including #include directly below
/usr/lib/snapd/snap-confine flags=(attach_disconnected) works. It don't
Ok, that makes a lot of sense. snap-confine needs to be update to work
on nfs (eg, add 'network inet, network inet6,'. Based on
'name="/home/r/"' it looks like you are still using the
'@{HOMEDIRS}+=/home/u/' change to the home tunable (or perhaps you
didn't reload snap-confine's profile after
Feb 9 09:57:30 hostname kernel: [ 2070.523056] audit: type=1400
audit(1486630650.755:1460): apparmor="DENIED" operation="sendmsg"
profile="/usr/lib/snapd/snap-confine" pid=15768 comm="snap-confine"
laddr=ip_of_local_host lport=917 faddr=ip_of_nfs_server fport=2049
family="inet"
Can you paste the output of "grep audit /var/log/syslog" at the time
right after the denial?
** This bug is no longer a duplicate of bug 1620771
when /home is somewhere else, snaps don't work
** Changed in: snapd (Ubuntu)
Status: Confirmed => Incomplete
--
You received this bug
*** This bug is a duplicate of bug 1620771 ***
https://bugs.launchpad.net/bugs/1620771
Thanks for the fast reply! Unfortunately, the problem is not solved.
The
@{HOMEDIRS}+=/home/*/
line solves the location issue (as in bug #1620771 and bug #1592696), but here
the location don't seems to be
*** This bug is a duplicate of bug 1620771 ***
https://bugs.launchpad.net/bugs/1620771
Thank you for filing a bug! This is essentially a duplicate of bug
#1620771. You have identified the issue precisely and need to update
@{HOMEDIRS} for your site. This can be done in a couple of ways such
55 matches
Mail list logo
