The same problem occurs on 24.04, but the workaround of setting the
ubuntu priority to a negative number seems to be working.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1999308
Title:
Snap keeps
Matthieu, more recently a more likely problem has been characterized by Alberto
Mardegan and found the line in question in
https://bugs.launchpad.net/snapd/+bug/1973321
In particular, restarting snapd doesn't help at all for me, so having
the directory mounted before snapd starts doesn't help, an
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 20.
I (using Kerberos) don't the get apparmor DENIED messages that Eric (not
using Kerberos) did, but I get exactly the same "cannot open path of the
current working directory: Permission denied" error.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed
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: P
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 prob
Firefox also doesn't work now it is a snap in 22.04.
I think there are still multiple issues here. The original poster seems
to be using NVSv3 I believe based on the RPC errors (NFSv3 uses multiple
ports, one of which is called something like RPC, but I am not an expert
in this as I have only used
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 lxd
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 m
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 complainin
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 OK
5.4.0-48-generic seems to have fixed this problem for me, thanks!
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1886277
Title:
Regression on NFS: unable to handle page fault in mempool_alloc_slab
T
For what it is worth, I also have the same enncryption aes256-cts-hmac-
sha1-96 (and same problem). The tickets come from MIT Kerberos on
Ubuntu 18.04; the NFS servers are Ubuntu 18.04 using krb5p security
option.
--
You received this bug notification because you are a member of Ubuntu
Bugs, whi
#3: Agreed that it is a duplicate of lp: #1886277 . Sorry, I looked for
similar bugs but did a lousy job it appears. I just made a comment to
this effect in #1886277.
#2: I believe the apport files are attached in comment #1, though it is
the first time I have used it and may be confusing it.
**
I also have this problem, which I reported as a new bug 1886775 which is
probably just a duplicate of this bug. Same issue, -40 dies with NFS
with similar stack trace and similar timing, -39 is fine, and multiple
hardware has the identical issues.
--
You received this bug notification because you
Thanks for fixing this! Much appreciated.
I tried to check that it worked, but possibly it has not gotten into
updates yet. How would I check?
[ running snap-store from the command line in home dir causes the error
"cannot open path of the current working directory: Permission denied".
Running fr
Public bug reported:
We use nfs mounted (using autofs), kerberos authenticated home
directories for most users.
Booting with kernel 5.4.0-40, users with nfs mounted home directories
find the system freezes not long after use, somewhat randomly. Power off
is then the only thing to do. Some specifi
It has been a constant problem for me in 18.04 but seems to work fine in
20.04 on the couple of computers I have tried it on.
However I have had reliability issues with it in 20.04 on one computer
with multiple ethernet adapters with only one plugged in and bridging
set up (for VMs). That may be j
Thanks Andreas,
I am not an expert either on kerberos or on security - I know enough to
be able to spot and verify a problem, but not enough to verify a
sufficient solution, so take what I way with that caveat in mind.
The section you have written seems reasonable, and that is indeed the
main att
I just tested restartung snapd while I am logged in via kerberos with an
autofs home directlry. It doesn't seem to help. In particular, I tried
launching system monitor (which uses snap) unsuccessfully. Using 18.04
with kerberos, and /home/ mounted via autofs.
Checking that /home is autofs will no
I don't know why krb5_validate is false by default. I thought it was
historical or to (dubiously) to make setting up easier, but I did some
tests and found, to my surprise, that even with it not set, I could not
log in without an /etc/krb5.keytab file.
In particular, I tried all 6 combinations of
Public bug reported:
This is similar to bugs 1662552 and 1782873. In 1782873, jdstrand asked
me to open a new bug for this specific issue.
In 1662552, snapd fails for nfs mounted home directories as network
permissions are not enabled. A work around was implemented that works if
the mount is done
*** This bug is a duplicate of bug 1662552 ***
https://bugs.launchpad.net/bugs/1662552
Jamie, I filed a new bug 1784774 as you requested. It feels like a
duplicate of this bug.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https
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 /
This seems similar to
https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1662552
The "fix" there is I believe only activated if you nfs mount /home at
boot, not by using autofs.
I have the same problem - I also use autofs to mount particular users
rather than all users (I want one local user wh
I also have observed this problem on bionic for several different
computers. The workaround always solves the problem; without the
workaround I cannot log in. What the computers had in common:
* Using bionic (either the version from the DVD or with network updates)
* Using networkd rather than Net
26 matches
Mail list logo
