/dev/shm isn't writable, causing problems with glibc 2.2+ apps such as chromium

[Noel J. Bergman]

Binary package hint: mountall

$ chromium-browser
[3008:3008:2715678973:ERROR:net/proxy/proxy_config_service_linux.cc(231)] Error requesting gconf directory: Failed to contact configuration server; some possible causes are that you need to enable TCP/IP networking for ORBit, or you have stale NFS locks due to a system crash. See http://projects.gnome.org/gconf/ for information. (Details - 1: Server ping error: IDL:omg.org/CORBA/COMM_FAILURE:1.0)
[3008:3016:2715679422:ERROR:base/shared_memory_posix.cc(192)] Creating shared memory in /dev/shm/org.chromium.ZhAyA5 failed: No such file or directory
[3008:3016:2715679458:ERROR:base/shared_memory_posix.cc(194)] This is frequently caused by incorrect permissions on /dev/shm. Try 'sudo chmod 777 /dev/shm' to fix.
[3008:3008:2715788286:ERROR:base/shared_memory_posix.cc(192)] Creating shared memory in /dev/shm/org.chromium.RfKF3e failed: No such file or directory
[3008:3008:2715788325:ERROR:base/shared_memory_posix.cc(194)] This is frequently caused by incorrect permissions on /dev/shm. Try 'sudo chmod 777 /dev/shm' to fix.
[3008:3008:2715788362:ERROR:base/shared_memory_posix.cc(192)] Creating shared memory in /dev/shm/org.chromium.9iSNwo failed: No such file or directory
[3008:3008:2715788376:ERROR:base/shared_memory_posix.cc(194)] This is frequently caused by incorrect permissions on /dev/shm. Try 'sudo chmod 777 /dev/shm' to fix.
[3008:3019:2715874235:ERROR:base/shared_memory_posix.cc(192)] Creating shared memory in /dev/shm/org.chromium.HehSdy failed: No such file or directory
[3008:3019:2715874263:ERROR:base/shared_memory_posix.cc(194)] This is frequently caused by incorrect permissions on /dev/shm. Try 'sudo chmod 777 /dev/shm' to fix.

See http://bugs.gentoo.org/show_bug.cgi?id=299777#c10, Bug 559545, Bug 532898 (a comment unrelated to the fixed bug that had observed "when the system is up, I have to "sudo chmod 777 /dev/shm" - otherwise various things (like Chromium) fail in a strange way" and many other references.

Applying the /etc/fstab fix suggested by gentoo:

  # See http://bugs.gentoo.org/show_bug.cgi?id=299777#c10
  shm /dev/shm tmpfs nodev,nosuid,noexec 0 0

does appear to resolve the problem, but other lucid systems have the correct permissions on /dev/shm without that entry. All of my lucid installs are up to date, so I'm not sure what the underlying cause is of the faulty permissions.

ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: mountall 2.13
ProcVersionSignature: Ubuntu 2.6.32-21.32-generic 2.6.32.11+drm33.2
Uname: Linux 2.6.32-21-generic x86_64
NonfreeKernelModules: nvidia
Architecture: amd64
Date: Mon Apr 19 11:50:29 2010
InstallationMedia: Ubuntu 10.04 "Lucid Lynx" - Alpha amd64 (20091209.1)
ProcEnviron:
 LANG=C
 SHELL=/bin/bash
SourcePackage: mountall

[Scott James Remnant (Canonical) (canonical-scott)]

Can you remove your "fix" and reboot, then run "cat /proc/self/mountinfo" and attach that?

Thanks

[Noel J. Bergman (noeljb)]

I reverted fstab to the preferred content and rebooted. /dev/shm has the correct permissions still/again. Do you still want mountinfo?

I'll definitely keep an eye out for this again, and post the mountinfo if /dev/shm ever again has the wrong permissions.

[Scott James Remnant (Canonical) (canonical-scott)]

Argh, that's a shame!

If it does happen, please do reopen the bug and post that information!

Thanks for the report

[Dima Ryazanov (dima-gmail)]

I ran into the same problem after upgrading to 10.04.

Here's /proc/self/mountinfo:

15 19 0:0 / /sys rw,nosuid,nodev,noexec,relatime - sysfs none rw
16 19 0:3 / /proc rw,nosuid,nodev,noexec,relatime - proc none rw
17 19 0:5 / /dev rw,relatime - devtmpfs none rw,size=2023880k,nr_inodes=505970,mode=755
18 17 0:12 / /dev/pts rw,nosuid,noexec,relatime - devpts none rw,gid=5,mode=620,ptmxmode=000
19 1 8:3 / / rw,relatime - ext3 /dev/disk/by-uuid/539db7ea-c0c3-4813-bee3-c58b460cacc9 rw,errors=remount-ro,data=ordered
20 15 0:15 / /sys/fs/fuse/connections rw,relatime - fusectl none rw
21 15 0:7 / /sys/kernel/debug rw,relatime - debugfs none rw
22 15 0:10 / /sys/kernel/security rw,relatime - securityfs none rw
23 17 0:16 / /dev/shm rw,nosuid,nodev,relatime - tmpfs none rw
24 19 0:17 / /var/run rw,nosuid,relatime - tmpfs none rw,mode=755
25 19 0:18 / /var/lock rw,nosuid,nodev,noexec,relatime - tmpfs none rw
26 19 0:19 / /lib/init/rw rw,nosuid,relatime - tmpfs none rw,mode=755
27 19 8:2 / /mnt/hardy rw,relatime - ext3 /dev/sda2 rw,errors=continue,data=ordered
28 27 0:5 / /mnt/hardy/dev rw,relatime - devtmpfs none rw,size=2023880k,nr_inodes=505970,mode=755
29 27 0:3 / /mnt/hardy/proc rw,nosuid,nodev,noexec,relatime - proc none rw
30 27 0:0 / /mnt/hardy/sys rw,nosuid,nodev,noexec,relatime - sysfs none rw
31 27 8:3 /tmp /mnt/hardy/tmp rw,relatime - ext3 /dev/disk/by-uuid/539db7ea-c0c3-4813-bee3-c58b460cacc9 rw,errors=remount-ro,data=ordered
32 19 8:2 /home /home rw,relatime - ext3 /dev/sda2 rw,errors=continue,data=ordered
33 19 8:5 / /mnt/jaunty32 rw,relatime - ext4 /dev/sda5 rw,barrier=1,data=ordered
34 33 8:2 /home /mnt/jaunty32/home rw,relatime - ext3 /dev/sda2 rw,errors=continue,data=ordered
35 33 0:5 / /mnt/jaunty32/dev rw,relatime - devtmpfs none rw,size=2023880k,nr_inodes=505970,mode=755
36 33 0:3 / /mnt/jaunty32/proc rw,nosuid,nodev,noexec,relatime - proc none rw
37 33 0:0 / /mnt/jaunty32/sys rw,nosuid,nodev,noexec,relatime - sysfs none rw
38 33 8:3 /tmp /mnt/jaunty32/tmp rw,relatime - ext3 /dev/disk/by-uuid/539db7ea-c0c3-4813-bee3-c58b460cacc9 rw,errors=remount-ro,data=ordered
39 16 0:20 / /proc/sys/fs/binfmt_misc rw,nosuid,nodev,noexec,relatime - binfmt_misc binfmt_misc rw

[Zack Evans (zevans23)]

Same problem here, appeared after a bunch of updates against the beta. Didn't have the problem on first install.

It's been consistent for a little while now, didn't report it straight away until I was sure it was EVERY time I rebooted. It's a real problem so by all means mark this "incomplete" again but don't mark it invalid - I'll provide whatever troubleshooting is needed.

Yes, I know the mount table is a mess. I'm reshuffling a few things. :-)

[Ruben M (rubenm)]

Same problem, after upgrading to Lucid and when installing a new version of chromium. Downgrading chromium didn't solve the problem.

$ chromium-browser
[5094:5094:10359541725:FATAL:base/shared_memory_posix.cc(193)] Creating shared memory in /dev/shm/org.chromium.DyN5DD failed. This is frequently caused by incorrect permissions on /dev/shm. Try 'sudo chmod 777 /dev/shm' to fix.: No such file or directory
Aborted

$ ls -ld /dev/shm/
drwxr-xr-t 2 root root 40 2007-10-05 18:45 /dev/shm/
$ grep shm /proc/self/mountinfo
24 17 0:16 / /dev/shm rw,nosuid,nodev,relatime - tmpfs none rw
$ grep shm /lib/init/fstab
none /dev/shm tmpfs nosuid,nodev 0 0

$ added in /etc/fstab with the options: nosuid,nodev,noexec,mode=1777 and works.
Are this the most appropiate options?

[Zack Evans (zevans23)]

I'm looking at a whole at a few bugs that I -didn't- have in a late beta and I DO have in the release versions. I thought I was going mad, but it does seem this appears between beta and current.

 I reinstalled fresh from the beta copy. This bug (/dev/shm permissions problem) does NOT appear in a fresh install from beta. It then reappeared directly after I updated mountall to the release version.

So this looks like some sort of regression between version 2.10 and version 2.15 of the package.

[Simon Schubert (corecode)]

Is there anything we can help to fix this bug? What are the temporary fix options?

[andrew thomas (atswartz)]

I am getting this in maverick
andrew@790Fx:~$ chromium-browser
[16682:16691:7522193672:FATAL:base/shared_memory_posix.cc(193)] Creating shared memory in /dev/shm/.org.chromium.pk526V failed. This is frequently caused by incorrect permissions on /dev/shm. Try 'sudo chmod 777 /dev/shm' to fix.: No such file or directory
Aborted (core dumped)
andrew@790Fx:~$ ls -ld /dev/shm/
drwxrwxrwt 2 root root 40 2010-09-13 18:29 /dev/shm/
andrew@790Fx:~$ grep shm /proc/self/mountinfo
22 16 0:16 / /dev/shm ro,relatime - tmpfs tmpfs ro
andrew@790Fx:~$ grep shm /lib/init/fstab
none /dev/shm tmpfs nosuid,nodev 0 0

[andrew thomas (atswartz)]

This line in /etc/fstab is the problem. Once I remove it, chromium starts up and works just fine.

none /dev/shm tmpfs nosuid,nodev 0 0

[Wessel Dankers (wsl)]

Regenerating the initrd fixed it for me:

    update-initramfs -k all -u

hth hand

[Daniel Hahler (blueyed)]

My workaround is to create a /etc/init/my-on-mounted.conf file, with the following content:

start on mounted
script
        chmod 777 /dev/shm
end script

[Tais P. Hansen (taisph)]

I do not have a line in /etc/fstab for /dev/shm and update-initramfs does not fix the problem for me.

[Steve Langasek (vorlon)]

/dev/shm is a tmpfs, and tmpfs in the kernel has a default mode of 01777. I don't see how this could be happening without a) an /etc/fstab entry overriding the /lib/init/fstab entry, or b) a rogue local script running at start-up that's changing the mode.

I certainly don't see any bugs in mountall here, and can't reproduce this - so if someone is still seeing this in 12.04, I'm afraid we're going to need more information to figure it out.

[Steve Langasek (vorlon)]

closing as invalid due to lack of information.

[Paul Okopny (paul-okopny)]

Having the same problem after update 16.10 -> 17.04. Have to do "sudo chmod -R a+w /dev/shm/" after each reboot.

cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
/dev/mapper/ubuntu--vg-root / ext4 errors=remount-ro 0 1
# /boot was on /dev/sda1 during installation
UUID=9a59ceda-072d-4648-93bc-847832b38fa4 /boot ext2 defaults 0 2
/dev/mapper/ubuntu--vg-swap_1 none swap sw 0 0

cat /proc/self/mountinfo | grep shm
26 20 0:21 / /dev/shm rw,nosuid,nodev shared:4 - tmpfs tmpfs rw

Any ideas?

[Paul Okopny (paul-okopny)]

Looks like in my case the problem is connected to "failed to connect to lvmetad falling back to device scanning" problem. No idea where to search for a solution so far.