Firefox and Chromium snaps preventing apps and devices from working correctly.

I also notice this isn't specific to ~/.cache but any hidden file or folder in your home directory so this will probably be a problem for many apps (off the top of my head I can think of cargo, pip, and many games, or game apps like PoL, Lutris, Steam, that install their documentation in dot directories). And working on projects where I need to view .html files, even inside my home folder (but in dot folders), has been a huge headache.

Hi,

Thank you for reporting this but, this is by design. Snaps can't access the user's home by default. However, they can write data to their own directories under home (e.g., /home/<user>/snap/<snap_name>/). Snaps can obtain access to the user's non-hidden files under home by connecting to the "home" interface (https://snapcraft.io/docs/home-interface) or by running without confinement (which isn't recommended). Access to hidden files can be obtained through the personal-files interface (https://forum.snapcraft.io/t/the-personal-files-interface/9357). The same also applies to /tmp. Snaps don't have full access to it by default, but they do have separate spaces under it (/tmp/snap.<snap_name>/tmp/).

Hi,

Yes, Firefox on SNAP is broken by design. I'm a long time user of Ubuntu and Firefox, and I've waited 3 months upgrading to 22.04 because of this choice of yours. I've finally upgraded and I'm not disappointed, my fears came true. I really don't want to go the chrome route.

I just hope that Ubuntu will not do this with the other applications, otherwise I'll switch right away to another distro.

I added firefox to the list of affected apps for more visibility.

I ran into this problem when Jupyter Lab failed to start, because it creates a temporary HTML file in $HOME/.local/share/jupyter/runtime/, and then opens it with the default web browser with "Access to the file was denied" error. It is weird that I can't even disable this "protection", not even telling that I don't see the need to protect hidden files in $HOME that much more than regular ones. Those that are really sensitive should be protected by access rights anyway.

I have been a loyal user of Xubuntu for quite many years, and intend to remain one for many years to come. Ubuntu decides to use snap for Firefox, fine. But I agree with an earlier poster that its current state qualifies for the adjective "broken". I, the user, not the Firefox packager, should be the one to decide whether or not Firefox should be allowed to read my hidden files and directories. That there is no easy way (or any way at all?) to fix that is just not reasonable.

I have just downloaded the Linux Firefox binary from Mozilla, in order to be able to use Firefox like I always have done. This is sad. I should really not have to do that for such a cornerstone of my OS-installation.

WebUSB is not working with the Chromium snap.

This prevents Google's Android Flash Tool from being used. The Android Flash Tool allows users to flash Android Factory and OTA Images. GrapheneOS also uses WebUSB for installing (and notes that it is broken on Ubuntu).

It also seems USBMidi isn't working, which prevents midi devices from being used with a lot of web software. This is especially important for Ubuntu Studio, which is meant to make these sorts of things more accessible.

The Chromium-based limitations are pushing people to recommend and opt for the non-snap Chrome (or even Edge) which is much less secure, more invasive, privacy unfriendly, and non-free software. So overall I feel like this is pushing people to proprietary software, outside of the repositories, and away from Chromium and Firefox (and Firefox is struggling as it is, it doesn't need more people driven away). Not to mention Ubuntu itself.

This bug breaks any application that uses firefox to open local files in /tmp for display. I'd politely suggest that breaking this sort of widely supported and used functionality for no clear benefit or advantage is perhaps not the best design choice. This is especially true when users can simply go out and download other versions that do support this functionality but may suffer from not being regularly and automatically updated.

If the issue is security then having an about:config option to pop up a window for permission to open local files that defaults to ON might be a better solution which leaves warnings and functionality in the hands of the user (the feature could be turned off in settings or by accessing about:config) but defaults to a more secure option for those that will likely never intentionally open local files.

I can only second much what has been said.

My Java IDE wants to open local Java API doc with my browser (Firefox in that case), and instead of opening the local doc, it shows me an error message because "file://" is pointing to a Snap sandbox or something alike and not to the root filesystem. This seems to indicate a major design flaw of the Firefox snap.

I assume there was a good reason for the Firefox team to switch to snap. However, a huge disadvantage of using Snap for Firefox is that it captured my Firefox profile from my home folder, stored it in the snap directory, and the removal of the snap package (because of the above reason) now all of a sudden also removes my profile, even without using --purge. This is dangerous!

Overall, snap or the Firefox snap seems to do a bad job in keeping apps and settings separated. Isn't the latter a really useful best practice in many Linuxes? I wonder why this important principle or useful tradition has been broken here.

This also breaks `rustup doc` for the same reason.

Running `snap connections firefox` I can see `personal-files` is already enabled.

It's trying to load:
/home/malachi/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/share/doc/rust/html/index.html
but gets access denied.

My Chrome is not loading via snap; so I can get around it by using Chrome instead of Firefox and loading the url myself instead of relying on the `rustup` tool.

This is still broken on the Firefox 108 snap.

(I have a similar use case: I'd like to local local copies of documentation from `rustup doc` and other sources.)

I am also affected when using `kde-open5 fish://hostname/myfile.html` that transparantly opens over ssh and saves temp file under .config. Switching to deb package because of this.

I have exactly the same problem that Mario (mario-gleirscher) reported on 2022-11-17. My Java IDE is Apache Netbeans, and if, for example, I want to look at the documentation for the Pattern class, it tries, and fails, to load the file "file:///usr/lib/jvm/java-11-openjdk-amd64/docs/api/java.base/java/util/regex/Pattern.html".

I understand that this is a design feature of Snap. However, it is also causing a serious regression in multiple pieces of widely used software. It's just NOT OK to break so much stuff, and to inconvenience so many people, over a packaging change.

Please fix this. There is no security issue in providing read-only access to documentation files.

[Edit: I see that firefox has a "firefox:system-packages-doc" connection, which allows access to /usr/share/doc. That's a step in the right direction, unfortunately that's incompatible with the way that Ubuntu manages Java releases.]

[Edit: And a workaround for those using Netbeans or similar systems. The actual java documentation is, in fact, stored under /usr/share/doc, but there's a symlink from, for example, "/usr/lib/jvm/java-11-openjdk-amd64" to "../../../share/doc/openjdk-11-jre-headless", which the snap installed application cannot traverse. It's possible, however, to configure Netbeans to look for the Javadoc under either "/usr/share/doc/openjdk-11-doc/api" or "/usr/share/doc/openjdk-11-jre-headless/api", which can be accessed, at least on my system].

I can't open certain e-mail-attachments which are important to me and my work, because Thunderbird places them in /tmp/pid-99999/ and opens them with my default browser.

I first thought, this should be easily fixable -- but no, there seems not to be a workaround (other than manually installing Firefox).

Seriously?!?

I wonder: What is going on in your minds?!? I'm using Kubuntu since it exists, but this is yet one more awkward thing slowly pushing me back to the search for another distro. It's one of the most common things to open an HTML-file in the /tmp/ -- being a software-developer I did this myself pretty often -- and you break such basic functionality and say "it's by design". Really?!?

This is a severe regression that absolutely needs to be fixed ASAP.

There are several tools and applications for various purposes produce HTML documentation or reports, that cannot be opened in Firefox.

For example:
- Intel Advisor: https://www.intel.com/content/www/us/en/docs/advisor/user-guide/2023-0/work-with-standalone-html-reports.html

- ARM performance reports: https://developer.arm.com/documentation/101137/1912/Interpreting-performance-reports

There are tons of other software that produce similar HTML reports (Autodesk Nastran, Comsol, ...)

As a developer, I reach into multiple other problems:

- I cannot access Sphinx or Doxygen generated HTML documentation
- Cython html annotations are not possible to access

All of the mentioned HTML files are residing in NFS-mounted folders that lie outside the users home directory, which I cannot access from the Snap Firefox.

This also breaks r-cran-plotly because it places the plots as html files in /tmp and tries to open them with firefox.

Status changed to 'Confirmed' because the bug affects multiple users.

 I can't open local html documentation in my home folder. While I understand the safety benefits of not giving your internet browser access to your personal files and I think it's a good thing ubuntu thinks about these issues firefox is also the main help browser on my system. There should be a way to launch an unconfined firefox to browse local documentation.

edit: I found out that the file I use is not actually inside my /home/ folder, because it is symlinked from another location:
the file is (for example) /home/myusername/myproject/doc.html , but /home/myusername/myproject is actually a symlink, pointing to /mnt/extrastorage/myusername/myproject/ .

So then I decided I should just give the firefox snap access to /mnt/extrastorage/myusername as well. Should be simple, no? But it turns out you can't???!? /home/ is *hardcoded* in the snap binary?

My first ubuntu version was 4.10 'Warty Warthog', so I'm rather used to ubuntu and hence rather reluctant to switching. But I fear snap will be the drop that overflows the bucket. please please please ubuntu, just use Flatpack. I get it, Flatpack is not perfect, but neither is Snap. And just like the the display manager fiasco Ubuntu's NIH syndrome cost the whole linux ecosystem years more to get Wayland finally (nearly) working.

But if you *insist* on doing your own thing (again), please make adding extra directories to the sandbox simpler.

I would just like to add another angry, frustrated, and probably redundant comment: I've been using Ubuntu since 2005, after switching from Debian because Ubuntu worked better out of the box for basic things like WiFi or watching videos. Over the years I've been very happy with Ubuntu, but now several times in the last few years I'm running into the problems caused by permissions in Snap (in the past for files in /tmp with pdftk, and now for files in ~/.<whatever> with Firefox). The answer always seems to be that the brokenness is "by design", but I don't understand why making something broken "by design" makes it okay: it's still broken, it's still a regression. And then there doesn't seem to be any way to simply disable the security mechanisms that are breaking these Snap packaged apps (e.g. here the solution, apparently, is to install Firefox from the Mozilla PPA as a regular .deb). I just want the Snap apps to be able to read files in /tmp and ~/.<whatever>. Why is this so hard?

Also, not only are these permission errors super annoying, they're also very confusing. They happen rarely, so I always seem to get confused and go through the same process:
1) get permission error about some file.
2) open terminal and check permissions of file: I have read access.
3) attempt to access file again from app and get same permission error.
4) Google the problem and find that it's caused by broken Snap permissions, where I didn't even know the app in question was managed by Snap (why would I, I used apt to install it ...).

Snapcraft: more like "crap snaf'd" :/

Well, I'm frustrated today because of 116.0.1.

I'm using Ubuntu 22.04, to avoid these issues I removed the snapped firefox and installed the apt-get version recommended in other sites.

It was happily running without problems until yesterday it was upgraded to 116.0.1 and firefox stopped working.

So, I decided today to move back to the default snap firefox, and here we are again, suffering with this problem.

I know is not a problem from firefox per-se, this is a problem of snap whose security model thinks that accessing /tmp folder is dangerous and didn't provide any workaround way to make it configurable :-(

And because of my last experience it seems that firefox is moving more and more to the snap version than to support the non-snap, which I find really really bad.

Question for others, is there a bug filed on snap about this flawed design about /tmp folder? I would like to add my voice there too.

Isn't

personal-files firefox:dot-mozilla-firefox :personal-files -

intended to allow access to hidden files/folders in the home directory? If so, it doesn't seem to work for the FF 110 snap.

I can only second the many frustrated comments here.