5

I recently upgraded to Ubuntu 20.04 from the 18.04 version. Since then, the snap-based chromium browser that comes with 20.04 is unable to access any items in the /opt partition which I have separately mounted on my system.

If I go to the trouble of installing a non-snap-based version of chromium, I do not have this problem under 20.04.

I'm not sure, but I think this problem with accessing filesystems outside of the one on which a snap program is running might be present in all snap-based software, not just chromium.

How can I get chromium and all other snap-based programs to see all the filesystems that I have mounted?

Thank you very much.

PS: On my system, /opt is mounted via the following line within /etc/fstab ...

UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx /opt ext4 defaults,auto 0 0

... where the x's take the place of an actual, valid UUID.

PPS: All non-snap-based software on my system has no trouble whatsoever in accessing anything on this /opt partition.

PPPS: The suggested solution in the referenced article does not solve my problem, because I would have to change my system around (changing mounts, paths, scripts, etc.), simply to get this crippled, snap-based chromium to work as it used to work before. My goal is to not change my long-standing system setup at all, but rather, to simply install a version of chromium which can run in the same way that I have been running it for years. The answer I have now posted shows the way I learned how to do this. After discovering that method to eliminate the snap-based chromium and replace it with the traditional version, it took me no longer than 10 minutes to replace chromium so that everything runs like it always has been able to run.

Improve this question
6
  • 1
    Does this answer your question? How to give snaps access to /somedir
    – vanadium
    Commented Oct 25, 2020 at 15:28
  • Thank you very much. I tried uninstalling the chromium snap and reinstalling, both with --devmode and with --classic. In both cases, I still couldn't access my /opt partition.
    – HippoMan
    Commented Oct 25, 2020 at 16:29
  • b.t.w. as I said in my answer, classic confinement has to be supported. It is not for Chromium, so that is not an option. ("Warning: flag --classic ignored for strictly confined snap chromium")
    – vanadium
    Commented Oct 25, 2020 at 17:26
  • Yes, I know what you said about it not working for classic confinement. I just tried it anyway, just in case, and not surprisingly, what you wrote is correct.
    – HippoMan
    Commented Oct 25, 2020 at 17:41
  • Update: see "NEW INFORMATION" which I added to my accepted answer. I discovered a way to run chromium from the original snap bundle, but without any containment restrictions.
    – HippoMan
    Commented Oct 27, 2020 at 17:50

4 Answers 4

Reset to default
10

NEW INFORMATION: I still stand by my opinion (now in the section prefaced with "MY ORIGINAL ANSWER (trimmed down)", below) that Ubuntu should offer both snap and non-snap versions of its packages instead of forcing us all to use the snap versions. However, I also discovered how to bypass the containment restrictions of the existing snap-based package:

If the standard Ubuntu snap-based chromium package is installed, we can run the program like this:

/snap/chromium/current/usr/lib/chromium-browser/chrome [ ... args ... ]

This bypasses the containment restrictions.

MY ORIGINAL ANSWER (trimmed down):

(Editorializing deleted) I have followed a suggestion in the following discussion which explains how to disable the crippled, snap-based chromium and to install a version which offers full capabilities, including the ability to access the filesystems which I want to access: How to remove snap completely without losing the Chromium browser?

I didn't remove snap completely ... all I did was perform the part of this that was suggested by the user called "eitch" (around 75% down towards the bottom of that discussion). Using this non-snap version of chromium solves my problem.

(Editorializing deleted)

UPDATE: Yet another solution would be for Ubuntu to offer both snap-based and non-snap-based packages for software such as chromium, so that each of us users could individually decide whether we want the full, traditional functionality of the given packages, or whether we want to install snap-based versions of the packages which make use of containment and might therefore have lesser functionality than the older versions. (Editorializing deleted)

ANOTHER UPDATE: I have now investigated this behavior under flatpak and appimage, and programs that are run via these services seem to have no trouble accessing all of the partitions and files on my system that are accessible via the command line. This containment restriction which cripples chromium apparently only applies only to snap.

Improve this answer
4
  • Neat and to me very unexpected finding. It indeed appears to fundamentally resolve your issue. Would be good to know why it works this way. If you edit the question and remove the ballast and personal opinion, I will upvote the answer.
    – vanadium
    Commented Oct 29, 2020 at 9:21
  • 1
    It appears you are bypassing "snap" and directly running the mounted binary code. So that probably does not establish the sandboxing. Again, great find!
    – vanadium
    Commented Oct 29, 2020 at 9:26
  • I think I understand why it would work this way. The snap-based containment is enforced via snap and snapd by means data which exists inside of /snap/chromium/current/usr/lib/SNAP-PACKAGE, and it sets up a fuse-based enviroment based upon all of this where certain filesystems are available and others are not. The executable within that directory tree is just a "normal" executable.
    – HippoMan
    Commented Oct 30, 2020 at 16:57
  • I also believe it is misguided to apply this kind of containment to a general-purpose piece of software like chromium. It makes sense, for example, that the certbot snap could enforce containment, given that it's a focused, special-purpose utility. However, all containment does for a general-purpose browser is to take away features that are intrinsic to that kind of software, and it thereby makes users' lives more complicated. Yes, this comment is editorializing, and as you can see, I've now removed a lot of the editorializing from my original answer.
    – HippoMan
    Commented Oct 30, 2020 at 17:01
5

Snaps, by design, are sandboxed. A snap can be connected to "interfaces" to allow them to do specific things. No interfaces are foreseen to allow a snap to access system folders. Even if such interface would exist, the packagers of Chromium still would need to enable connecting the interface to the snap.

In general, you can have a snap access a specific folder (a "separately mounted file system" is, once it is mounted, just a folder structure) by a mount --bind of that folder under a folder where the snap has access.

Some snaps can be installed in "classic" mode. "Classic mode" removes all sandboxing, and hence all security. Installing in classic mode is only possible if the snap has been prepared for that. Publishing a classic snap requires manual approval of the snap store maintainers. Therefore, many snaps cannot be installed in classic mode.

Perhaps, however, you should reconsider your workflow: do you really need your browser to access /opt?

Improve this answer
8
  • Yes, I need my browser to access /opt. I have procedures which depend on URL's such as file:///opt/path/to/somewhere. I don't want to restructure my entire Ubuntu filesystem setup and/or a number of scripts and procedures that have been in use for a couple years, just because it was decided to only offer chromium as a snap nowadays.
    – HippoMan
    Commented Oct 25, 2020 at 14:55
  • 1
    I wouldn't mind the decision to offer a snap-based version of chromium and other software if non-snap versions of these same items were also offered. I now understand and support Linux Mint's decision to not support snap packages without the user's prior consent. See this article: ghacks.net/2020/06/16/…
    – HippoMan
    Commented Oct 25, 2020 at 15:04
  • I forgot to mention above that I tried mount --bind /opt /home/myusername/mnt/opt (after creating ~/mnt/opt) with the snap-based chromium, but file:///home/myusername/mnt/opt/path/to/somewhere just hung forever in snap-based chromium, despite the fact that I could easily cd into that directory and access anything I want there from the command line.
    – HippoMan
    Commented Oct 25, 2020 at 16:43
  • You have to mount in a folder where the snap has access, i.e. under the chromium's snap or if the document interface is enabled, under Documents, Movies, etc. Even that solution will require you to change your paths. See the question of which I in the end marked this question as duplicate: essentially with snap, you currently cannot use any path you want. By the way, this is not at all related to you mounting a separate file system.
    – vanadium
    Commented Oct 25, 2020 at 17:21
  • 1
    Understood. Thankfully, my solution of replacing the snap version of chromium with the non-snap version solved my problem relatively quickly and easily. IMO, certain software should not be made into a snap package in the first place. Anyway, thank you for all your feedback and explanation.
    – HippoMan
    Commented Oct 25, 2020 at 17:56
2

For similar reasons, I gave up on the snap-based Chromium and use Google Chrome instead (which comes as a .deb package). I can only recommend that.

Improve this answer
1
  • This is the sane answer. Snap version breaks too much, has random hidden paths that only the developers at snap know about, ties your hands in so many ways.
    – run_the_race
    Commented Mar 17, 2022 at 9:26
1

Start root shell by

env SHELL=/bin/bash sudo -s

Thereafter, to be able to use data under /opt in Chromium, do

snap connect chromium:removable-media
mkdir -p /media/opt
echo "/opt    /media/opt    none    bind" >>/etc/fstab
mount -a
exit

Then you should be able to use /opt via /media/opt in Chromium.

If you need only temporary access, replace the echo line and the mount line above by

mount --bind /opt /media/opt

To be able to use possible submounts, too, use rbind instead of bind.

You can use all mounted filesystems via /mnt/r/ by running

mount --rbind / /mnt/r

(as superuser) if directory /mnt/r exists.

See here for instructions on how to unmount an rbind mount.

Note that there may be security risks in mounting all the extra filesystems.

See here for information about the removable-media interface.

Improve this answer
4
  • Thank you very much. This would get me only part of the way towards what I want. There are scripts. utilities, and user procedures which all reference /opt, and they would all have to be changed to refer to /media/opt, simply so that the Ubuntu version of chromium could be utilized. This is still needless work, IMO, since it's easier to simply bypass the snap version of that program altogether and use the non-snap version which I have now already installed.
    – HippoMan
    Commented Oct 26, 2020 at 13:24
  • @HippoMan no, you can continue to use /opt like before even if you do the additional mounting.
    – jarno
    Commented Oct 26, 2020 at 19:58
  • Hmm ... I think I see what you mean. If the original /opt in fstab is mounted to /media/opt instead, then the addtional bind mount that you describe would also allow it to be referred to as /opt. I guess that chromium could then also see it as /opt without having to refer to it there as /media/opt, correct?
    – HippoMan
    Commented Oct 27, 2020 at 17:55
  • The original mount applies, but the additional mount makes the tree available on /media/opt, too. I guess not, but you could experiment.
    – jarno
    Commented Oct 28, 2020 at 7:10

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .