Ticket #12166 (closed defect: fixed)

Opened 2 years ago

Last modified 22 months ago

VBoxClient does not startup because of permissions in /opt/VBoxGuestAdditions-X.X.X directory (bug + fix found) -> fixed as of 22 October 2013 (4.1 branch and later)

Reported by: DrChaos Owned by:
Priority: major Component: installer
Version: VirtualBox 4.2.18 Keywords: guest additions permission installer opt
Cc: Guest type: Linux
Host type: Windows


My symptom was that I could not cut and paste between my host and guest, even though I selected bidirectional clipboard. I confirmed bidirectional clipboard was turned on correctly through VBox.log on the Windows host.

My Linux client is Scientific Linux 6.4, which is nearly exactly RHEL 6.4 (up to date). VirtualBox version is 4.2.18

There were no VBoxClient processes running and /usr/bin/VboxClient pointed to an unreadable path.

I found that the /opt/VBoxGuestAdditions-4.2.18/ did not have read or execute permissions open for unprivileged users. The problem persisted after I uninstalled the guest additions, deleted /opt/VBox*, rebooted, and reinstalled guest permissions.

The problem was fixed when I changed the permissions on /opt/VBoxGuestAdditions-4.2.18/ to allow read+exec for general users. After a reboot, the VBoxClient processes were running normally and clipboard worked. Furthermore I no longer have to do "xrandr -s 0" every time I resize the guest window.

This appears to be a regression from ticket #10832 which showed other problems from an /opt/ permissions problem which was supposedly fixed, but has reoccurred in my environment.

It should be an easy fix in the installer, but this problem bugged me for weeks until I found the problem.


Change History

comment:1 Changed 2 years ago by michael

A look at the installer script suggests that this should only be possible if the directory /opt/VBoxGuestAdditions-4.2.18 already existed with the wrong permissions before you installed the Additions. Can you try to reproduce this without that prerequisite in case I am wrong? I will write a fix for that particular case.

comment:2 Changed 23 months ago by DrChaos

I confirmed this. I ran /opt/VBoxGuestAdditions-4.2.18/ as root, confirmed that /opt/ was empty, and then ran the guest additions installer again. After the installer ran the permissions are still --- for users.

[root@dg0txcs1-vm1 opt]# ls -al /opt
total 12
drwxr-xr-x.  3 root root 4096 Oct 10 23:02 .
dr-xr-xr-x. 29 root root 4096 Oct  8 11:36 ..
drwxrwx---.  9 root root 4096 Oct 10 23:03 VBoxGuestAdditions-4.2.18

I do chmod 775 VBoxGuestAdditions* to make it work properly.

This issue may solve some other bugs I saw---such as screen not resizing properly, which was one of my symptoms (all because the additions were not all running properly because of the permissions).

[root@dg0txcs1-vm1 opt]# uname -a
Linux 2.6.32-358.18.1.el6.x86_64 #1 SMP Tue Aug 27 14:23:09 CDT 2013 x86_64 x86_64 x86_64 GNU/Linux

[root@dg0txcs1-vm1 opt]# umask

comment:3 Changed 23 months ago by DrChaos

OK, I have some more information. The problem seems to occur when I start the installation of the Guest Additions using the GUI window (I think it is GNOME) for the VBOXADDITIONS_4.2.18_88780 window, i.e. automatically mounted. I click on "Open Autorun Prompt" and install it that way, and the problem comes, /opt/VBoxGuestAdditions-4.2.18 ends up with permissions 770.

When I run the manually from command line as root, then the permissions end up at 755 as the installer script appears to force in the 'mkdir'.

So there is something in the "autorun" environment under GNOME which I don't understand at all which is causing the problem.

Version 0, edited 23 months ago by DrChaos (next)

comment:4 Changed 23 months ago by michael

Could this be a umask issue on your guest?

comment:5 Changed 23 months ago by michael

  • Summary changed from VBoxClient does not startup because of permissions in /opt/VBoxGuestAdditions-X.X.X directory (bug + fix found) to VBoxClient does not startup because of permissions in /opt/VBoxGuestAdditions-X.X.X directory (bug + fix found) -> fixed as of 22 October 2013 (4.1 branch and later)

I added code to manually set the umask, and will assume that was the problem unless I get more feedback.

comment:6 Changed 22 months ago by frank

  • Status changed from new to closed
  • Resolution set to fixed

Fixed in 4.3.2.

Note: See TracTickets for help on using tickets.
ContactPrivacy policyTerms of Use