** 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 Ubuntu
Bugs, 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 Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1784774
Title:
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 Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1784774
Title:
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 Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1784774
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
Still an issue in:
$ snap version
snap2.54.3+20.04.1ubuntu0.2
snapd 2.54.3+20.04.1ubuntu0.2
series 16
ubuntu 20.04
kernel 5.13.0-30-generic
$ pycharm-community
cannot create user data directory: /home/adam/snap/pycharm-community/267: Stale
file handle
$ brackets
cannot create user
I'm sorry to be that guy. But the fix does not seem to work for me :(
rohdef@ubuntu ~> snap version
snap2.49.1
snapd 2.49.1
series 16
ubuntu 20.10
kernel 5.8.0-1019-raspi
rohdef@ubuntu ~> lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu Hirsute
** Changed in: snapd
Status: Fix Committed => Fix Released
** Changed in: snapd (Ubuntu)
Status: Confirmed => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1784774
Title:
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
** 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/1784774
Title:
snapd is not autofs aware and fails with nfs home dir
To manage
This is now fixed by https://github.com/snapcore/snapd/pull/8936
** Changed in: snapd
Status: Triaged => In Progress
** Changed in: snapd
Milestone: None => 2.46
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
With the additional information in
https://bugs.launchpad.net/snapd/+bug/1821193 I think we can fix this
issue quickly.
1) The mountinfo parser will now look for an automount point that
mentions autofs, an example line is mentioned here:
137 29 0:50 / /home rw,relatime shared:87 - autofs
@zyga any update on this?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1784774
Title:
snapd is not autofs aware and fails with nfs home dir
To manage notifications about this bug go to:
I'm sorry for not fixing this yet. A few higher priority bugs kept me
busy lately. I will look at fixing it next Monday, with a bit of hope it
may be easy and I can get it done without shuffling other planned work.
--
You received this bug notification because you are a member of Ubuntu
Bugs,
I'd like to confirm Andrew Conway's report. Restarting snapd does not
change anything.
Could you at least up the priority of the bug. After all it's been there
for quite a while, it's been confirmed and people have worked and are
working on it. Just a little push to solve it. Pretty please! :-)
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
** Also affects: snapd
Importance: Undecided
Status: New
** Changed in: snapd
Assignee: (unassigned) => Zygmunt Krynicki (zyga)
** Changed in: snapd
Status: New => Triaged
** Changed in: snapd
Importance: Undecided => Medium
--
You received this bug notification
The issue is NFS detection only happens at snapd start, and on boot no
NFS shares are mounted yet.
If an AutoFS NFS user logs in, and then snapd is restarted, NFS support
is enabled
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
snapd will not work properly with users' homes that are unavailable if
the user is not logged in. As a workaround, schedule refreshes to only
happen when all the local users are logged in.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
This is still broken on bionic, AutoFS mounted home directories are not
detected
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1784774
Title:
snapd is not autofs aware and fails with nfs home dir
With snap and snapd 2.35.2, it seems to be working for me now.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1784774
Title:
snapd is not autofs aware and fails with nfs home dir
To manage
I created a patch to workaround this problem:
https://github.com/bryant1410/snapd/commit/a9831da29aba7a4905647ff582061ac399a3b240
It's basically hardcoding a value. I'm not sure what the correct
behavior should be for all the cases that /home is autofs, or if it
should check that /home/user is NFS
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 Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1784774
Title:
33 matches
Mail list logo
