Call for testing: chromium 62.0.3202.62


Known issue with snapd rejecting URLs passed to xdg-open without a scheme. I just filed bug #1729777 to keep track of it.


I am able to reproduce the nvidia failure on Ubuntu 17.10. I suspect hitting the issue depends on the nvidia driver version. I use nvidia-384.

After a bit of debugging it turns out that one of the helper processes of chromium runs: mknod("/dev/nvidiactl", S_IFCHR|0666, makedev(195, 255)) which is not allowed. Its unclear why it is trying to mknod this device because it is already available in the namespace that chromium runs in.

AppArmor denial for /dev/nvidiactl

With a bit more data from strace I get the following picture:

[pid  6555] stat("/dev/nvidiactl", {st_dev=makedev(0, 6), st_ino=487, st_mode=S_IFCHR|0666, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=0, st_rdev=makedev(195, 255), st_atime=2017-11-03T12:14:40+0100.694587974, st_mtime=2017-11-03T12:14:40+0100.694587974, st_ctime=2017-11-03T12:14:40+0100.694587974}) = 0
[pid  6555] --- SIGSYS {si_signo=SIGSYS, si_code=SYS_SECCOMP, si_errno=ENOENT, si_call_addr=0x7fc59eaf002d, si_syscall=__NR_open, si_arch=AUDIT_ARCH_X86_64} ---
[pid  6555] stat("/dev/nvidiactl", 0x7ffc10066500) = -1 EPERM (Operation not permitted)
[pid  6555] mknod("/dev/nvidiactl", S_IFCHR|0666, makedev(195, 255)) = ?

What is odd is that the stat("/dev/nvidiactl") works and then stops working.


is it possible to run this snap in Ubuntu Core?
maybe using the mir-kiosk setup (or otherwise)


Corresponding bug report.


With the help of @popey and @oSoMoN, we found that adding mknod to the seccomp policy allows things to work. We then looked at an strace of chromium with the policy change and discovered that chromium is unconditionally and AFAICT needlessly doing mknod()s, getting EPERMs and then doing an open(), which succeeds. Because the default snapd policy disallows mknod, this process is killed in strict mode, thus resulting in the black screen. This is a chromium bug; chromium should not be calling mknod() on an existing file which wouldn’t succeed anyway.

Now, if snapd’s seccomp sandbox sent EPERM instead of kill (see the upcoming, then that chromium process wouldn’t be killed and things should just work. Using mknod on character and block devices requires CAP_MKNOD to be able to successfully create devices and apparmor mediates this capability. As a result, we can add a workaround rule to the browser-support policy by adding mknod - |S_IFCHR but with a corresponding audit deny capability mknod, apparmor rule which will make it so that the chromium process won’t be killed on mknod, but it still won’t be able to create character devices. When we set the seccomp policy to EPERM instead of kill, this workaround policy can be removed.

@popey, can you report back with the test instructions I gave on IRC (ping me on IRC if you have trouble).


@jdstrand the change you posted to me on irc worked. I was able to launch the chromium snap on my nVidia based laptop with your mods.


I’ll get this fixed in the policy updates for 2.30.

#49 has the workaround rules.


U2F (Universal 2nd Factor) isn’t working when signing into my gmail account trying to use my yubikey. This is a USB device which IIRC chromium needs bidirectional communication with.


Seems that HTML5 +DRM video playback doesn’t work: Netflix redirects to their help page (


DRM video playback was broken in the chromium ubuntu package (deb) until version 63 that has been published earlier this week (see bug #1652110). Even with that fixed version, you still need two things to make this work:

  • have google-chrome installed (it provides the actual content decryption module, called widevine, which we cannot ship for legal reasons)
  • override the user agent string to pretend to be chrome (netflix does user agent sniffing)

This won’t work with a snap, because for the same legal reasons it cannot ship the CDM library, and it will not be able to see it if it’s installed on the system because of strict confinement (unless we punch a hole in the security profile to allow access to /opt/google/chrome/


That wouldn’t work anyway, since the snap’s runtime environment won’t use /opt from the host. What could work is if you were able to trick chromium to look for it somewhere within the snap’s area, then have instructions for the user copy the file to this area.


Thanks for the suggestion! This is now being tracked by bug #1738149.


I have an old yubikey from 2012 that doesn’t support U2F, unfortunately, so I can’t test this myself.

I have filed bug #1738164 to track the issue, could you please look into apparmor/seccomp denials and attach your findings to the bug report? Thanks!


Thanks @jdstrand. I’ve just had access to a laptop with a nvidia GPU running the proprietary driver, and I can confirm that the chromium snap works with snapd 2.30 from the candidate channel.


Work on 18.04 daily with nvidia proprietary drivers, using:

snap    2.30+git476.f91a849~ubuntu16.04.1
snapd   2.30+git476.f91a849~ubuntu16.04.1
series  16
ubuntu  18.04
kernel  4.13.0-17-generic


Snap is working on Arch Linux,

Snap version:

[syntist@Syntist-PC ~]$ snap version
snap      2.30.r285.g7855e9512-1
snapd     2.30.r285.g7855e9512-1
series    16
kernel    4.14.8-1-ARCH

[syntist@Syntist-PC ~]$ snap list
Name      Version       Rev   Developer  Notes
chromium  62.0.3202.94  128   canonical  -
core      16-2.30       3748  canonical  core

Nvidia Driver:

[syntist@Syntist-PC ~]$ cat /proc/driver/nvidia/version
NVRM version: NVIDIA UNIX x86_64 Kernel Module  387.34  Tue Nov 21 03:09:00 PST 2017
GCC version:  gcc version 7.2.1 20171128 (GCC) 

But no H/W Acceleration.

Call for testing: chromium 65.0.3325.146

well using the app is fine.

I think my Spotify sound was interupted at 1m:41s into installing the snap.
Both Spotify and chromium are installed on Bionic Beaver as a snap, so since these are newer versions - it would be nice to solve this disapointing problem.


For the most part, the app works fine but I have had a pause of around ten seconds once or twice on Ubuntu 18.04 on an Entroware Orion. Few and far between though.

Edit: Actually, logging into my Google account for bookmarks stopped the snap from loading. Running snap run chromium produces this:

Gtk-Message: Failed to load module "canberra-gtk-module"
Gtk-Message: Failed to load module "canberra-gtk-module"
ATTENTION: default value of option force_s3tc_enable overridden by environment.
Gkr-Message: secret service operation failed: An AppArmor policy prevents this sender from sending this message to this recipient; type="method_call", sender=":1.118" (uid=1000 pid=14766 comm="/snap/chromium/274/usr/lib/chromium-browser/chromi" label="snap.chromium.chromium (enforce)") interface="org.freedesktop.DBus.Peer" member="Ping" error name="(unset)" requested_reply="0" destination="org.freedesktop.secrets" (uid=1000 pid=1658 comm="/usr/bin/gnome-keyring-daemon --daemonize --login " label="unconfined")

Using v65.0.3325.181

…also, the snap is using the older icon. Any chance of a refresh, please?