virtualbox: Error opening file for reading

Bug #1014487 reported by Paul Jackson on 2012-06-18
This bug affects 16 people
Affects Status Importance Assigned to Milestone
virtualbox (Ubuntu)

Bug Description

I have just upgraded my Kubuntu system from 11.10 to 12.04, and then installed virtualbox. I have gotten far enough to install Oracle_VM_VirtualBox_Extension_Pack, so that I can use USB 2.0, and to add myself to the vboxusers group. I have not yet started installing Windows XP inside my new virtualbox.

I am seeing the following error on both version 4.1.12 (in the 12.04 release) and in the latest downloadable version from Oracle 4.1.16.

Everytime I start up virtualbox, I get the error:

[CODE]Error opening file for reading: Permission denied[/CODE]

Running strace on this process (well, seems I have to run it on the shell within which I start virtualbox) I can see the following:

15128 open("/proc/self/auxv", O_RDONLY) = -1 EACCES (Permission denied)
15128 dup(2) = 19
15128 fcntl(19, F_GETFL) = 0x8002 (flags O_RDWR|O_LARGEFILE)
15128 fstat(19, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 0), ...}) = 0
15128 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fe3d6b13000
15128 lseek(19, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek)
15128 write(19, "Error opening file for reading: "..., 50) = 50
15128 close(19) = 0

This error does not seem to cause a problem, and the virtualbox session proceeds without further problems.

Looking about the web, I see that virtualbox is apparently trying to open /proc/self/auxv in order to determine some system capabilities, and that it is realized that this is not a reliable method -- auxv may or may not be readable.

In my situation, auxv is reliably NOT readable .

The following shell command reliably shows the contents of what is, I suspect, the desired auxv information:

[CODE]LD_SHOW_AUXV=1 /bin/true[/CODE]

For example on my Kubuntu 12.04 amd64 system, it shows:

AT_SYSINFO_EHDR: 0x7fffcd7c4000
AT_HWCAP: bfebfbff
AT_PHDR: 0x400040
AT_BASE: 0x7ffc2640c000
AT_ENTRY: 0x401134
AT_UID: 1000
AT_EUID: 1000
AT_GID: 1000
AT_EGID: 1000
AT_RANDOM: 0x7fffcd772489
AT_EXECFN: /bin/true

The following code might provide a useful and reliable means of parsing this auxv information:

#include <stdio.h>
#include <string.h>
#include <stdlib.h>

 * The following flgets() and examine_auxv() routines are Copyright
 * 2006 and 2012 respectively by Paul Jackson <email address hidden>.
 * These routines are free software; you can redistribute them and/or
 * modify them under the terms of the GNU Lesser General Public
 * License as published by the Free Software Foundation; either
 * version 2 of the License, or (at your option) any later version.
 * This library is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * Lesser General Public License for more details.
 * You may obtain a copy of this license from: <>.

 * char *flgets(char *buf, int buflen, FILE *fp)
 * Obtain one line from input file fp. Copy up to first
 * buflen-1 chars of line into buffer buf, discarding rest
 * of line. Stop reading at newline, discarding newline.
 * Nul terminate result and return pointer to buffer buf
 * on success, or NULL if nothing more to read or failure.
 * Paul Jackson
 * <email address hidden>
 * 20 Feb 2006

static char *flgets(char *buf, int buflen, FILE * fp)
    int c = -1;
    char *bp;

    bp = buf;
    while ((--buflen > 0) && ((c = getc(fp)) >= 0)) {
        if (c == '\n')
            goto newline;
        *bp++ = c;
    if ((c < 0) && (bp == buf))
        return NULL;

    if (c > 0) {
        while ((c = getc(fp)) >= 0) {
            if (c == '\n')

    *bp++ = '\0';
    return buf;

 * int examine_auxv(const char *pattern, char *buf, int buflen)
 * Examine /proc/self/auxv, as formatted in the manner
 * seen by running the command:
 * LD_SHOW_AUXV=1 /bin/true
 * Return the first line that has some substring matching
 * the input "pattern". Return up to the first (buflen-1)
 * characters of that line, nul-terminated, in the provided
 * buffer "buf".
 * Only the first buflen-1 characters of each line are examined
 * for the input pattern. If that pattern is not entirely
 * contained within those buflen-1 characters, it will not
 * found on that line.
 * Return zero if a match is found and placed in buf, else
 * return -1 and (in most cases - see popen(3) man page)
 * set errno appropriately. If no match is found, the
 * buffer buf is overwritten with the last line of input
 * from the above command.
 * Paul Jackson
 * <email address hidden>
 * 17 June 2012

int examine_auxv(const char *pattern, char *buf, int buflen)
    char *bp;
    FILE *fp;

    fp = popen("LD_SHOW_AUXV=1 /bin/true", "r");
    while ((bp = flgets(buf, buflen, fp)) != NULL) {
        if (strstr(bp, pattern) != NULL) {
            return 0;
    return -1;

 * Test case for above:

#define BUFLEN 256
char buf[BUFLEN];

int main(int argc, char *argv[])
    int i;

    for (i = 1; i < argc; i++) {
        if (examine_auxv(argv[i], buf, BUFLEN) == 0)
            printf ("%s ==> %s\n", argv[i], buf);

Launchpad Janitor (janitor) wrote :

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

Changed in virtualbox (Ubuntu):
status: New → Confirmed
josete (muallin) wrote :

Also affects virtualbox 4.1.18, on my ubuntu 12.04 64bit

I tried an strace , but could not see any "denied" error.

José Sá (upsfeup) wrote :

To anyone who is trying to replicate and capture this error with strace. I had to:

sudo chmod u+s /usr/bin/strace
sudo -u <username> strace -f -o vbox.out VirtualBox

Paul Jackson (pj-usa) wrote :

The way I got the strace output, without having to make the strace binary setuid root, was to note the pid of my shell (echo $$), then in another terminal window, invoke strace as root on that shell. Then within the now strace'd shell, run virtualbox under my normal user id.

CharlesA (charlesa) wrote :

Does VirtualBox actually launch? I'm getting the same "Error opening file for reading: Permission denied" when launched VBox 4.1.18 (from the virtualbox repos) but VirtualBox loads up fine.

I'm running vbox as a non sudo user on 12.04 x64 server.

Have you made a thread over on the virtualbox forums/submitted a bug report?

Paul Jackson (pj-usa) wrote :

Yes, virtualbox starts and works fine. I've just spent several hours in it, doing various Windows XP installs and configurations ... virtualbox worked flawlessly.

I am also running virtualbox on a 12.04 x64 system, non-super user.

I have not submitted any bug report to Oracle/virtualbox -- just this bug report to ubuntu.

CharlesA (charlesa) wrote :


I just tested it on Ubuntu 12.04 as an admin user and still got the same error, but VBox started just fine.

I have posted a question over on the virtualbox forums:

CharlesA (charlesa) wrote :

Bug report filed at

I make a aptitude purge virtualbox-4.1 and a fresh package install from

worked fine for me.

Paul Jackson (pj-usa) wrote :

wasare wrote:
>> I make a aptitude purge virtualbox-4.1 and a fresh package install from
>> worked fine for me.

I only see the failure when running virtualbox as non-root.


One more important detail: the failing open of /proc/self/auxv apparently comes from the following file:

lrwxrwxrwx 1 root root 16 Jan 13 06:54 /usr/lib/x86_64-linux-gnu/ ->

I say this for two reasons:
1) Just a few lines before the failing open in my strace, the most recent open is of this library.
2) Scanning -all- the files opened in that strace, the -only- one of them that held the string "auxv" was this library.

Apparently libjpeg-turbo8 (the package that owns this library on my Kubuntu 12.04 system) is opening auxv in order to determine if some advanced SIMD instructions (MMX, SSE2, NEON) are available, to accelerate baseline JPEG compression.

Felix Geyer (debfx) on 2012-06-29
Changed in virtualbox (Ubuntu):
importance: Undecided → Low
Paul Jackson (pj-usa) wrote :

Downloading libjpeg-turbo with this command:

bzr branch lp:ubuntu/precise/libjpeg-turbo

and searching the source code for "auxv", it seems that on my system (x86_64, but not APPLE) that the code tries to open /proc/self/auxv, and complains perror("Error opening file for reading") if the open fails, in the file: libjpeg-turbo/jlibinit.c

"aptitude purge virtualbox-4.1 and a fresh package install from"

Fixed the trouble running virtualbox as non-root and root user.

After i received the message: "Failed to load VMMR0.r0 (VERR_SUPLIB_WORLD_WRITABLE)"

Fixed with:
chmod 0755 /usr

Now, when running from a terminal I get these message:

Error opening file for reading: Permission denied
Qt WARNING: QSpiAccessible::accessibleEvent not handled: "8008" obj: QObject(0x0) " invalid interface!"

But virtual box is working.

Paul Jackson (pj-usa) wrote :

Wanderson Santiago dos Reis (wasare) :

The problem you are concerned with is NOT the problem this bug is concerned with.

Virtualbox has been working all along for me, all the time.

The only problem I am reporting in this bug report is the message "Error opening file for reading: Permission denied"

I have not seen, and this bug report is not reporting, a virtualbox failure with message "Failed to load VMMR0.r0 (VERR_SUPLIB_WORLD_WRITABLE)"

Paul Jackson (pj-usa) wrote :

Looking through the libjpeg code, it says in a README to send bug reports to <email address hidden>.

So I have just sent the following message there:

As reported at, and at, recent versions of virtualbox (in Ubuntu 12.04 and the latest download from Oracle) are (sometimes) issuing an error message on startup:

Error opening file for reading: Permission denied

I have tracked this down to the perror() on line 49 of libjpeg-turbo/jlibinit.c.

I am seeing the error when I start up virtualbox as a non-root user, though just why /proc/self/auxv would not be readable by the current non-root user at that point in its startup is not clear to me.

I posted code in the first post of the first link above (see the routines flgets() and examine_auxv()) which -might- be more reliable. But it's using a sledge hammer to swat flies, calling popen("LD_SHOW_AUXV=1 /bin/true", "r") and scanning the output via a pipe ... so I'll be surprised if you find it suitable.

CharlesA (charlesa) wrote :

Thanks Paul. I'm not quite sure if this adds anything, but when I tested it on my 12.04 desktop box, /proc/self/auxv had permissions set to -r-------- (400) with the user and group set t whoever is logged in at the time.

In the case of my desktop - that is whoever is logged in either via ssh or desktop login:

vbox@Thor:~$ ls -ld /proc/self/auxv
-r-------- 1 vbox vbox 0 Jun 29 07:53 /proc/self/auxv

charles@Thor:~$ ls -l /proc/self/auxv
-r-------- 1 charles charles 0 Jun 29 07:53 /proc/self/auxv

Same on the server.

Paul Jackson (pj-usa) wrote :

>> ... when I tested it on my 12.04 desktop box, /proc/self/auxv had permissions
>> set to -r-------- (400) with the user and group set t whoever is logged in at the time.

Well, /proc/self always links to the current process's /proc entry. It is just a short hand
for /proc/PID, where PID is the return from getpid(), or in most shells, the value of $$.

So I would have expected any virtualbox process to be able to read its own /proc/self/auxv,
as that special file would be owned by itself (and as you noticed, has permissions set to
allow the file owner to read it.)

It remains a mystery to me that a virtualbox process often can't read this auxv file.

Paul Jackson (pj-usa) wrote :

Aha - /usr/lib/virtualbox/VirtualBox is setuid root, and then lowers its privilege to the invoking user, with a
pair of setresgid and setresuid calls, prior to the failure to open /proc/self/auxv. Perhaps the auxv file
retains its root ownership across these events, which would make it unable to be opened (EPERM) by
the non-root invoker.

Tuomas Silen (tuomas-silen) wrote :

The "Error opening file for reading" is caused by Ubuntu's patch to libjpeg-turbo library. I opened a separate bug report for it to libjpeg-turbo package here:

The error message should be nonfatal, just obscure when it appears in application logs.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.