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.04, not 22.04 ] Yay! that is the first time I have seen a snap actually work with my normal user account. This feels like significant progress in working out what is going on! Of course firefox needs access to the home directory to load the profile and store downloads. Is the whole process run as some other user (a la sudo) or is there just some starting stub running as some other user doing something that returns to the actual user after doing something that thinks it needs access to the current directory but could get by without it? Actually, I can sort of answer that - I tried running "musescore" as a snap, starting from / It successfully ran. I tried saving something, and it sort of did... but in a new, empty "home" directory in a /home/arc/snap/musescore/216/ that the save file dialog went to when I pressed the home button. Is this normal behaviour for a snap? Regardless of the inconvenience of the subdirectory, that is running over nfs successfully. I can close Musescore and load it again. But not with cwd=/home/arc. So that is fairly strong evidence supporting your idea that it is the same root cause as https://bugs.launchpad.net/bugs/1973321 . I will add a comment there. Thanks for the insight Alberto! -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to firefox in Ubuntu. https://bugs.launchpad.net/bugs/1784774 Title: snapd is not autofs aware and fails with nfs home dir Status in snapd: Fix Released Status in firefox package in Ubuntu: Confirmed Status in snapd package in Ubuntu: Incomplete Bug description: 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 via a /home mount at boot. However this does not work if people mount home directories via autofs. This is probably the fundamental problem for 1782873 although there may be other issues. [ Why use autofs? If some but not all of users want to use nfs homes. In particular, I have a local user on all my accounts that does not require the nfs server to be up or the kerberos server to be up, or kerberos working on the client machines, etc. It is very useful when something goes wrong. It means I mount /home/user rather than /home (for several users). ] To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1784774/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
