user@jammy:~$ cd /
user@jammy:/$ firefox
cannot create user data directory: /home/p00000012366/snap/firefox/1670: Permission denied
Hi @eoli3n! Any AppArmor denials in the logs? Maybe paste here the output of journalctl -b -t audit.
root@jammy:~# journalctl -b -t audit | grep firefox
août 22 11:16:26 jammy audit[650]: AVC apparmor="STATUS" operation="profile_load" profile="unconfined" name="snap-update-ns.firefox" pid=650 comm="apparmor_parser"
août 22 11:16:26 jammy audit[661]: AVC apparmor="STATUS" operation="profile_load" profile="unconfined" name="snap.firefox.firefox" pid=661 comm="apparmor_parser"
août 22 11:16:26 jammy audit[662]: AVC apparmor="STATUS" operation="profile_load" profile="unconfined" name="snap.firefox.geckodriver" pid=662 comm="apparmor_parser"
août 22 11:16:26 jammy audit[663]: AVC apparmor="STATUS" operation="profile_load" profile="unconfined" name="snap.firefox.hook.configure" pid=663 comm="apparmor_parser"
août 23 11:30:10 jammy audit[78801]: AVC apparmor="DENIED" operation="mkdir" profile="snap-update-ns.firefox" name="/usr/share/libreoffice/help/" pid=78801 comm="5" requested_mask="c" denied_mask="c" fsuid=0 ouid=0
But only the last line is related to today test.
OK, so it doesnât look like AppArmor is to blame here. Just for debugging, please try using the no_root_squash mount option, and see if that helps.
As another test, try doing
# let's first check the existing permissions:
ls -l /home/p00000012366/snap/firefox
chmod a+rwx /home/p00000012366/snap/firefox
and then starting firefox again.
user@jammy:/$ ls -l /home/p00000012366/snap/firefox
total 0
drwxr-xr-x 2 user p00000012366 10 mai 9 11:16 1300
drwxr-xr-x 2 user p00000012366 10 août 23 11:30 1670
drwxr-xr-x 2 user p00000012366 10 mai 9 11:16 common
lrwxrwxrwx 1 user p00000012366 4 août 23 11:30 current -> 1670
user@jammy:/$ chmod a+rwx /home/p00000012366/snap/firefox
user@jammy:/$ firefox
cannot create user data directory: /home/p00000012366/snap/firefox/1670: Permission denied
Iâm searching about how to automount home with no_root_squash
Thanks. What does snap info firefox say? Itâs strange that itâs attempting to create 1670 when itâs already there.
Also please try the above chmod command with -R, to make it recursive.
root@jammy:~# snap info firefox
name: firefox
summary: Mozilla Firefox web browser
publisher: Mozillaâ
store-url: https://snapcraft.io/firefox
contact: https://support.mozilla.org/kb/file-bug-report-or-feature-request-mozilla
license: unset
description: |
Firefox is a powerful, extensible web browser with support for modern web application
technologies.
commands:
- firefox
- firefox.geckodriver
snap-id: 3wdHCAVyZEmYsCMFDE9qt92UV8rC8Wdk
tracking: latest/stable/ubuntu-22.04
refresh-date: Il y a 14 jours, Ă 16 h 23 HNR
channels:
latest/stable: 103.0.2-1 2022-08-09 (1670) 171MB -
latest/candidate: 104.0-3 2022-08-23 (1749) 185MB -
latest/beta: 105.0b1-1 2022-08-22 (1742) 187MB -
latest/edge: 106.0a1 2022-08-23 (1748) 182MB -
esr/stable: 91.12.0esr-1 2022-07-26 (1588) 161MB -
esr/candidate: 102.2.0esr-2 2022-08-22 (1739) 182MB -
esr/beta: â
esr/edge: 102.1.0esr-1 2022-07-26 (1592) 169MB -
installed: 103.0.2-1 (1670) 171MB -
user@jammy:~$ chmod -R a+rwx /home/p00000012366/snap/firefox
user@jammy:~$ firefox
cannot create user data directory: /home/p00000012366/snap/firefox/1670: Permission denied
OK, it looks like itâs not an issue with the DAC permissions either. Then the last thing to try is no_root_squash, which would mean that we are essentially hitting https://bugs.launchpad.net/snapd/+bug/1973321, though in this case the behaviour is slightly different so not even starting the snap from / helps.
I tried to set no_root_squash in autofs client side, but when i restart the service and umount/remount my home, the option seems ignored (not listed in mount command). Is there something to change server side ?
EDIT : Iâm with network guy, and he will export homes temporally with no_root_squash option
Ok, firefox is working with home exported as âno_root_squashâ. But it is a security issue right ?
EDIT : ⊠I reverted to root_squash, rebooted the client, and firefox is still working ⊠I canât explain
It works probably because the directory layout has been created in the previous run (that with the no_root_squash option), so even now that you restored the original setup, the operation does not need to be repeated.
Itâs strange that â as far as I know â there are no other reports for this exact issue. Either people are not using that option, or there might have been something else in your setup that caused the system to take this path.
Anyway, please keep the options as you had originally, and letâs see if the issue comes back (did you try it on different user accounts?).
After fighting against a new snapd malfunction, I canât even install firefox. The task is running endlesslyâŠ
root@jammy:~# ps aux | grep firefox
root 6418 0.3 1.8 96504 73468 ? S 15:07 0:01 /usr/bin/apt-get -y -o Dpkg::Options::=--force-confdef -o Dpkg::Options::=--force-confold install firefox=1:1snap1-0ubuntu2 firefox-locale-fr=1:1snap1-0ubuntu2
root 6457 0.1 3.6 163384 147548 pts/2 Ss+ 15:07 0:00 /usr/bin/dpkg --force-confdef --force-confold --status-fd 62 --no-triggers --unpack --auto-deconfigure /var/cache/apt/archives/firefox_1%3a1snap1-0ubuntu2_amd64.deb /var/cache/apt/archives/firefox-locale-fr_1%3a1snap1-0ubuntu2_all.deb
root 6664 0.0 0.4 1089040 16144 pts/2 Sl+ 15:12 0:00 snap info firefox
root 6672 0.0 0.0 17748 2408 pts/3 S+ 15:12 0:00 grep --color=auto firefox
If I run snap list or snap info firefox it hangs.
EDIT : I get
**erreur : cannot list snaps: cannot communicate with server: timeout exceeded while waiting for response**
I confirm that firefox is still working with the same user.
I cleaned home directory
$ rm -Rf snap .*
And firefox is still working.
Trigger snapd after multi-user.target maybe fix the nfs detection, but it then break snap installation with ansible-pull that I run before lightdm.
Is there a way to force nfs-support in any cases ?
Faced that issue again with a new snap package âintellij-idea-ultimateâ.
Here exports line from exportfs -v
/virt 162.38.80.0/21(ro,async,wdelay,crossmnt,root_squash,no_subtree_check,fsid=0,sec=sys,ro,secure,root_squash,no_all_squash)
/virt/home 162.38.80.0/21(rw,async,wdelay,no_root_squash,no_subtree_check,sec=sys,rw,secure,no_root_squash,no_all_squash)
Is it possible to have the NFS server run in verbose mode, and see what file accesses are getting denied?
Iâm asking this because itâs still very unclear to me what is causing these issues.
Ok I think I get what happened :
I face again the first problem we had, nfs-support trigger. Because if snapd starts without a home mounted as NFS then network inet rules are not set.
The first workaround I tried is to force snapd to start AFTER multi-user.target. But then it triggers another problem : multi-user.target is reach when lightdm is ready. But I use a custom ansible-pull service, which installs some snap package, and force to start it before lightdm. I do this to force the user to wait for the host to be fully configured before beeing able to login. So the problem is that ansible-pull needs snapd to run before lightdm, but we explicitly tell snapd to run AFTER lightdm. So it breaks at each snap package install.
I removed that workaround, so now Iâm facing the first issue again.
I will try to force nfs support for snap by
$ cat << EOF > /var/lib/snapd/apparmor/snap-confine/nfs-support
network inet,
network inet6,
EOF
$ chattr +i /var/lib/snapd/apparmor/snap-confine/nfs-support
But I think snapd should be configurable to force nfs support from one config file.
cannot run daemon: state startup errors: [cannot synchronize snap-confine policy: rename /var/lib/snapd/apparmor/snap-confine/nfs-support.R8JQfyYBKTRn~ /var/lib/snapd/apparmor/snap-confine/nfs-suppo
chattr +i is then not possible. And at reboot, sometimes, the file is removed.
Please give me the solution to have permanent nfs-support
EDIT: as discussed on libera.chat#snappy, there is no way to force nfs-support manually for now.
as a new workaround : adding a fake nfs mount to fstab
# nfs-support snapd workaround
server:/fake /mnt/fake nfs defaults,nofail,x-systemd.device-timeout=0 0 2
At each reboot, the file /var/lib/snapd/apparmor/snap-confine/nfs-support seems to exist.
EDIT : related bug https://bugs.launchpad.net/snapd/+bug/1917348
The workaround is not working at startup, after a reboot:
root@si22:~# file /var/lib/snapd/apparmor/snap-confine/nfs-support
/var/lib/snapd/apparmor/snap-confine/nfs-support: cannot open `/var/lib/snapd/apparmor/snap-confine/nfs-support' (No such file or directory)
root@si22:~# systemctl restart snapd
root@si22:~# file /var/lib/snapd/apparmor/snap-confine/nfs-support
/var/lib/snapd/apparmor/snap-confine/nfs-support: ASCII text
root@si22:~# grep nfs /etc/fstab
server:/snapd-nfs-support-workaround /mnt/fake nfs defaults,nofail,x-systemd.device-timeout=0 0 2
Here snapd logs, we can see that at first boot, before restarting snapd, it doesnât detect anything.
-- Boot c768b0d8b527449580c8a7d952279590 --
sept. 23 08:06:53 si22 systemd[1]: Starting Snap Daemon...
sept. 23 08:06:54 si22 snapd[661]: AppArmor status: apparmor is enabled and all features are available
sept. 23 08:06:55 si22 snapd[661]: AppArmor status: apparmor is enabled and all features are available
sept. 23 08:06:55 si22 snapd[661]: overlord.go:263: Acquiring state lock file
sept. 23 08:06:55 si22 snapd[661]: overlord.go:268: Acquired state lock file
sept. 23 08:06:55 si22 snapd[661]: daemon.go:247: started snapd/2.57.1 (series 16; classic) ubuntu/22.04 (amd64) li>
sept. 23 08:06:55 si22 snapd[661]: daemon.go:340: adjusting startup timeout by 1m35s (pessimistic estimate of 30s p>
sept. 23 08:06:58 si22 systemd[1]: Started Snap Daemon.
sept. 23 08:07:32 si22 snapd[661]: main.go:155: Exiting on terminated signal.
sept. 23 08:07:32 si22 systemd[1]: Stopping Snap Daemon...
sept. 23 08:07:32 si22 snapd[661]: overlord.go:504: Released state lock file
sept. 23 08:07:32 si22 systemd[1]: snapd.service: Deactivated successfully.
sept. 23 08:07:32 si22 systemd[1]: Stopped Snap Daemon.
sept. 23 08:07:32 si22 systemd[1]: snapd.service: Consumed 6.983s CPU time.
sept. 23 08:07:32 si22 systemd[1]: Starting Snap Daemon...
sept. 23 08:07:32 si22 snapd[1863]: AppArmor status: apparmor is enabled and all features are available
sept. 23 08:07:32 si22 snapd[1863]: AppArmor status: apparmor is enabled and all features are available
sept. 23 08:07:32 si22 snapd[1863]: overlord.go:263: Acquiring state lock file
sept. 23 08:07:32 si22 snapd[1863]: overlord.go:268: Acquired state lock file
sept. 23 08:07:32 si22 snapd[1863]: daemon.go:247: started snapd/2.57.1 (series 16; classic) ubuntu/22.04 (amd64) l>
sept. 23 08:07:32 si22 snapd[1863]: daemon.go:340: adjusting startup timeout by 1m35s (pessimistic estimate of 30s >
sept. 23 08:07:32 si22 snapd[1863]: backend.go:135: snapd enabled NFS support, additional implicit network permissi>
sept. 23 08:07:36 si22 systemd[1]: Started Snap Daemon.