*** This bug is a duplicate of bug 1917348 ***
https://bugs.launchpad.net/bugs/1917348
I'm closing this bug and setting it as a duplicate of
https://bugs.launchpad.net/snapd/+bug/1917348
There are several issues related to NFS and remote filsystems in
general, and we will be tackling them
** Changed in: snapd (Ubuntu)
Status: Incomplete => Confirmed
** Changed in: snapd (Ubuntu)
Importance: Undecided => High
** Changed in: firefox (Ubuntu)
Importance: Undecided => High
--
You received this bug notification because you are a member of Desktop
Packages, which is
Thanks Alberto. I tried running "hello" in a different directory, and
you were correct:
arc@andrewfairfield:~$ hello
cannot open path of the current working directory: Permission denied
arc@andrewfairfield:~$ cd /
arc@andrewfairfield:/$ hello
Hello, world!
arc@andrewfairfield:/$
[ This is in
Hi Erik, I see now what's the problem (this is specific to your setup --
this probably does not concern other people who commented here): your
home directories are under /staff, whereas currently snaps only support
the traditional /home// scheme.
Please subscribe to
Thanks Erik and Andrew for the logs!
It looks like we have more than one bug here:
1) Andrew's logs show that after restarting the snapd service, NFS was
correctly detected and there are no more AppArmor denials on that. But
on Erik's machine, for some reason, that did not happen.
2) Even if
Using NVFv4, kerberos authenticated, mounted by autofs:
arc@andrewshoreham:~$ hello
cannot open path of the current working directory: Permission denied
[ Then as user with sudo privs, sudo systemctl restart snapd ]
arc@andrewshoreham:~$ hello
cannot open path of the current working directory:
Yes, we are using Autofs.
thisisme@jammy:~$ cat /etc/auto.staff
* -rw,nosuid nfshome.domain.edu:/nfshome/staff/&
thisisme@jammy:~$ cat /etc/auto.master
/facauto.fac --timeout=120
/staff auto.staff --timeout=120
thisisme@jammy:~$ pwd
/staff/thisisme
thisisme@jammy:~$
I believe that this is a duplicate of bug 1884299.
A few questions to people affected by this bug:
1) are you using autofs?
2) can you please try running "sudo systemctl restart snapd" after
logging in into your $HOME, and then try running a snap again?
3) If that still fails, can you paste
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: snapd (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: firefox (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
reopening for snapd since it seems it's not firefox specific and still
an issue
** Changed in: snapd (Ubuntu)
Status: Fix Released => New
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
I got exactly the same errors as Miles above; a simple permission denied
error stopping things before AppArmor got involved.
I.e., the answer to Markus Kuhn's question is no, in fact even in
enforce mode there are no denied apparmor complaints.
I don't know whether this is because the gating
Running the snap 'hello' gives the following message in
/var/log/kern.log:
kernel: [25832.721379] audit: type=1400 audit(1650864430.846:486):
apparmor="ALLOWED" operation="open" profile="/usr/sbin/sssd"
name="/proc/26293/cmdline" pid=827 comm="sssd_nss" requested_mask="r"
denied_mask="r" fsuid=0
It may also be worth noting that Kerberos/GSSAPI authentication for NFS
works a bit differently from Kerberos/GSSAPI authentication for
applications, because NFS happens in the kernel, and therefore the
kernel needs to get access to the Kerberos tickets (credentials). The
kernel's NFS client does
I did some more investigating, and I think there are two independent problems
here:
(1) The problem as believed so far, network access permissions
(2) New insight: Kerberos doesn't work with snaps.
This explains why fixing (1) didn't help me (or Adam).
Background: Kerberos is the authentication
I never got it to work in 20.04, so I don't know whether your fix ever
made it in.
I have just installed Jammy Jellyfish (22.04), and can confirm snaps
don't work in it when using autofs and nfs mounted home directories.
The prior work around was just never use any snap applications, which
was
16 matches
Mail list logo
