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.

HippoMan
  • 535

4 Answers4

11

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.

HippoMan
  • 535
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?

vanadium
  • 97,564
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.

HuHa
  • 3,525
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.

jarno
  • 6,175