Bugzilla – Bug 1174406
Virtual Box USB passthrough
Last modified: 2021-02-15 18:56:46 UTC
Created attachment 839923 [details] Virtualbox LOG file since the last update of Virtualbox the USB passthrough doesn't work anymore. The ~/.config/VirtualBox/VBoxSVC.log sais: "00:00:01.695707 nspr-5 WARNING [COM]: aRC=NS_ERROR_FAILURE (0x80004005) aIID={16ced992-5fdc-4aba-aff5-6a39bbd7c38b} aComponent={HostWrap} aText={VirtualBox is not currently allowed to access USB devices. You can change this by adding your user to the 'vboxusers' group. Please see the user manual for a more detailed explanation}, preserve=true aResultDetail=0" However, I am member of the group 'vboxusers': "Johannes@JohannesOffice:~> id uid=1000(johannes) gid=100(users) Gruppen=100(users),457(vboxusers),486(kvm)" My Configuration: openSUSE Tumbleweed 20200717 KDE-Plasma-Version: 5.19.3 KDE-Frameworks-Version: 5.72.0 Qt-Version: 5.15.0 Kernel-Version: 5.7.7-1-default Art des Betriebssystems: 64-bit Prozessoren: 4 × AMD Ryzen 3 2200G with Radeon Vega Graphics Speicher: 13,6 GiB Arbeitsspeicher Grafikprozessor: AMD RAVEN
What are the results of the command 'ls ~/.config/VirtualBox/'?
Created attachment 839976 [details] Directory Contents
I tested a Win 10 VM using VB 6.1.10 with kernel 5.7.7. I then did the upgrade to VB 6.1.12 with kernel 5.7.9. USB passthru worked with both setups. Your system contains file ~/.config/VirtualBox/enable, which is needed to setup passthru. I have no idea what might be wrong. To make sure that the VB devices are correct, run the following command and post your output: cat /usr/lib/udev/rules.d/60-vboxdrv.rules My system contains the following: KERNEL=="vboxdrv", NAME="vboxdrv", OWNER="root", GROUP="root", MODE="0600" KERNEL=="vboxdrvu", NAME="vboxdrvu", OWNER="root", GROUP="root", MODE="0666" KERNEL=="vboxnetctl", NAME="vboxnetctl", OWNER="root", GROUP="root", MODE="0600" SUBSYSTEM=="usb_device", ACTION=="add", RUN+="/usr/lib/virtualbox/VBoxCreateUSBNode.sh $major $minor $attr{bDeviceClass}" SUBSYSTEM=="usb", ACTION=="add", ENV{DEVTYPE}=="usb_device", RUN+="/usr/lib/virtualbox/VBoxCreateUSBNode.sh $major $minor $attr{bDeviceClass}" SUBSYSTEM=="usb_device", ACTION=="remove", RUN+="/usr/lib/virtualbox/VBoxCreateUSBNode.sh --remove $major $minor" SUBSYSTEM=="usb", ACTION=="remove", ENV{DEVTYPE}=="usb_device", RUN+="/usr/lib/virtualbox/VBoxCreateUSBNode.sh --remove $major $minor"
Hello my /usr/lib/udev/rules.d/60-vboxdrv.rules is: KERNEL=="vboxdrv", NAME="vboxdrv", OWNER="root", GROUP="root", MODE="0600" KERNEL=="vboxdrvu", NAME="vboxdrvu", OWNER="root", GROUP="root", MODE="0666" KERNEL=="vboxnetctl", NAME="vboxnetctl", OWNER="root", GROUP="root", MODE="0600" SUBSYSTEM=="usb_device", ACTION=="add", RUN+="/usr/lib/virtualbox/VBoxCreateUSBNode.sh $major $minor $attr{bDeviceClass}" SUBSYSTEM=="usb", ACTION=="add", ENV{DEVTYPE}=="usb_device", RUN+="/usr/lib/virtualbox/VBoxCreateUSBNode.sh $major $minor $attr{bDeviceClass}" SUBSYSTEM=="usb_device", ACTION=="remove", RUN+="/usr/lib/virtualbox/VBoxCreateUSBNode.sh --remove $major $minor" SUBSYSTEM=="usb", ACTION=="remove", ENV{DEVTYPE}=="usb_device", RUN+="/usr/lib/virtualbox/VBoxCreateUSBNode.sh --remove $major $minor" As far as I can see, it is exactly what you have. Maybe I forgot to tell, that the USB-passthrough was working very well, but after the updates last week (or the week before) it stopped working. I still don't know what changed.
Just anogher question: what is owner:group of the /usr/lib/udev/rules.d/60-vboxdrv.rules? For me it is root:root and I can't change it (or do I have to reboot after changing the group?) Furhtermore I have 2 60-vboxdrv.rules: 1. /etc/udev/rules.d 2. /usr/lib/udev/rules.d Both are identical, although the directory /usr/lib/udev/rules.d contains many rules, /etc/udev/rules.d only 2 besides the vbox rules.
The correct owner:group for /usr/lib/udev/rules.d/60-vboxdrv.rules is root:root. The permissions should be -rw-r--r-- (0644). The vbox rules in /etc/udev/rules.d are left over from the change that moved stuff out of /etc into subdirectories of /usr. In /etc/udev/rules.d, I have only 2 files - 70-persistent-ipoib.rules and 70-persistent-net.rules. Please delete /etc/udev/rules.d/60-vboxdrv.rules and try again. It probably will not make any difference, but it is worth a try. I am suspicious that there may be other extraneous files in /etc on your system, but with 380 directories and 2754 files in /etc that search could take a while.
Indeed, removing /etc/udev/rules.d/60-vboxdrv.rules didn't help anything. In the /usr/lib/udev/rules.d directory there are plenty 60-*.rules files: JohannesOffice:/usr/lib/udev/rules.d # dir 60-* -rw-r--r-- 1 root root 8595 2020-07-22 18:39 60-autosuspend-chromiumos.rules -rw-r--r-- 1 root root 703 2020-06-17 11:03 60-block.rules -rw-r--r-- 1 root root 1417 2020-06-17 11:03 60-cdrom_id.rules -rw-r--r-- 1 root root 413 2020-06-17 11:03 60-drm.rules -rw-r--r-- 1 root root 990 2020-06-17 11:03 60-evdev.rules -rw-r--r-- 1 root root 394 2020-06-17 11:03 60-fido-id.rules -rw-r--r-- 1 root root 282 2020-06-17 11:03 60-input-id.rules -rw-r--r-- 1 root root 793 2020-02-04 22:56 60-io-scheduler.rules -rw-r--r-- 1 root root 582 2020-07-05 01:36 60-mdevctl.rules -rw-r--r-- 1 root root 616 2020-06-17 11:03 60-persistent-alsa.rules -rw-r--r-- 1 root root 2710 2020-06-17 11:03 60-persistent-input.rules -rw-r--r-- 1 root root 7925 2020-06-17 11:03 60-persistent-storage.rules -rw-r--r-- 1 root root 2135 2020-06-17 11:03 60-persistent-storage-tape.rules -rw-r--r-- 1 root root 769 2020-06-17 11:03 60-persistent-v4l.rules -rw-r--r-- 1 root root 856 2020-07-22 15:23 60-rdma-persistent-naming.rules -rw-r--r-- 1 root root 5551 2020-07-15 11:37 60-scdaemon.rules -rw-r--r-- 1 root root 736 2020-06-17 11:03 60-sensor.rules -rw-r--r-- 1 root root 1190 2020-06-17 11:03 60-serial.rules -rw-r--r-- 1 root root 747 2020-07-23 00:20 60-vboxdrv.rules Could any of those files be the problem? Over at the virtualbox forums there is someone with the same problem as me: https://forums.virtualbox.org/viewtopic.php?f=7&t=99112 In this thread someone points to https://en.opensuse.org/VirtualBox I guess, this page has to be updated, because it sais you have to copy the 60-vboxdrv.rules to the /etc/udev/rules.d directory.
There should be lots of 60-xxx files in /usr/lib/udev/rules.d/. My system has all of those plus one other. They are not the problem. The problem in the VirtualBox Forum is with Leap 15.2. The common factors are Windows 10 guest and version 6.1.2 of VB. I need to make a fresh installation of Leap 15.2 anyway, which will give me a chance to try to duplicate that other persons setup. If I get a failure, then I will have a change to find out exactly what failed by including debugging statements. Yes, that wiki page needs revision.
I created a new 15.2 instance with VB 6.1.10. USB passthru worked. I updated it to 6.1.12 using my local repo, and it still worked. In your log, I noted 00:00:00.000692 main Executable: /usr/lib/virtualbox/VBoxSVC On my system, the executable is /usr/lib/virtualbox/VirtualBoxVM VBoxSVC starts the XPCOM server. How are you starting your VM? Are you specifying the USB device in the USB Device Filters section of the GUI, or from the Devices Tab of the VM?
For whatever it may be worth, my setup in Leap 15.2 as host with Win10 as guest in VB 6.1.12_SUSEr139181 has a 60-vboxdrv.rules file in usr/lib/udev/rules.d/, but not in /etc/udev/rules.d/ Copying the 60-vboxdrv.rules file from the former into the latter with the given lines uncommented (they weren't commented anyway) made no difference - still no USB in the VM. (An oddity is that the USB mouse and keyboard both work in the VM, but no other USB device is detected even though they exist)
The USB rules file should NOT be in /etc/udev/rules.d/. The correct directory is /usr/lib/udev/rules.d/. The mouse and keyboard are never treated as USB devices, even though they may be attached in that way. The virtual mouse and keyboard devices are attached to the abstracted host devices. I am surprised that /etc/udev/rules.d/ has any files given the recent moving of files from /etc into /usr/lib; however, my brand-new Leap 15.2 instance has 55-libsane.rules, 56-sane-backends-autoconfig.rules, and 70-persistent-net.rules in that directory. It appears that sane has not yet been converted, but the persistent-net rule is a mystery.
(In reply to Larry Finger from comment #9) > I created a new 15.2 instance with VB 6.1.10. USB passthru worked. I updated > it to 6.1.12 using my local repo, and it still worked. > > In your log, I noted > 00:00:00.000692 main Executable: /usr/lib/virtualbox/VBoxSVC > > On my system, the executable is /usr/lib/virtualbox/VirtualBoxVM > > VBoxSVC starts the XPCOM server. How are you starting your VM? Are you > specifying the USB device in the USB Device Filters section of the GUI, or > from the Devices Tab of the VM? Hi, I start VirtualBox from the GUI "Virtual Box". Before I was starting it from the Device Tab. But now now devices are listed anymore.... :-( Also, when I try to use the USB Device Filter section of the GUI, it only tells mie: "No Devices available".... :-( Maybe I have to install the machine from scratch...
I also tried to start the VM like this: ~> /usr/lib/virtualbox/VirtualBoxVM --startvm Win10 Qt WARNING: QXcbConnection: XCB error: 3 (BadWindow), sequence: 28794, resource id: 18885919, major code: 40 (TranslateCoords), minor code: 0 Qt WARNING: QCursor: Cannot create bitmap cursor; invalid bitmap(s) Win10 starts, but still no USB Devices... The warnings are unrelated to my problem... calling VBoxSVC is not possible: ~> /usr/lib/virtualbox/VBoxSVC VBoxSVC: error: Failed to register the server name "VBoxSVC-6.1.12_SUSE" (rc=NS_ERROR_FAILURE)! VBoxSVC: error: Is another server already running? XPCOM server has shutdown. Also calling help on VBoxSVC doesn't tell me how to specify the vm...
I was hoping to be able to recreate the problem here, but that seems unlikely. I will create a version that has debug info regarding the USB failure. Once I have that, I will tell you where the modified binaries can be found. I hope it will not be long.
The problem is in starting the USB thread. As there are 5 or 6 places for failure, I have added printouts at each place. Once I know which failure is happening, then I can put more effort into that place. The new binaries are at https://build.opensuse.org/package/binaries/home:lwfinger:branches:Virtualization/virtualbox/openSUSE_Factory. You will need to download and install (with zypper) the following: python3-virtualbox-6.1.12-554.1.x86_64.rpm virtualbox-6.1.12-554.1.x86_64.rpm virtualbox-qt-6.1.12-554.1.x86_64.rpm For 15.2 users, your binaries are at https://build.opensuse.org/package/binaries/home:lwfinger:branches:Virtualization/virtualbox-kmp/openSUSE_Leap_15.2. Download and install the same set of binaries. After running the new code, post the Log from the Virtual Machine. That should contain the printouts to get me started on the next part.
Created attachment 840099 [details] New VBox Log New VBox log herewith (I hope I got that right)
Created attachment 840117 [details] VBoxSVC.log
Thanks. As expected, the logs show a permissions problem. Finding why that happens in the code gets a bit more complicated. Where did the VBoxSVC.log come from? I could not find that on my machine. What is the output of 'VBoxManage list usbhost'? If that shows nothing, then run 'strace VBoxManage list usbhost >> host_list.txt 2>&1' and post host_list.txt.
Created attachment 840121 [details] hostlist.txt
Sorry, the output is like this: " ~> VBoxManage list usbhost Host USB Devices: <none> " Then I tried your second command and attached to the post before (sorry for this). VBoxSVC.log is from the Directory "~/.config/VirtualBox/". there are another 10 Backup (VBoxSVC.log.x). Thanks, Johannes
Another comment: when I do "sudo VBoxManage list usbhost" I get the following output: VBoxManage list usbhost Host USB Devices: UUID: d6f00faf-8b29-4f91-bb0f-b86753304cb7 VendorId: 0x0a5c (0A5C) ProductId: 0x2101 (2101) Revision: 0.0 (0000) Port: 2 USB version/speed: 2/Full Manufacturer: Broadcom Corp Product: BCM92045DG Non-UHE Address: sysfs:/sys/devices/pci0000:00/0000:00:08.1/0000:06:00.3/usb3/3-3//device:/dev/vboxusb/003/002 Current State: Busy UUID: 91445cb1-7a65-43e8-9697-b010f35b3086 VendorId: 0x062a (062A) ProductId: 0x4102 (4102) Revision: 1.3 (0103) Port: 8 USB version/speed: 1/Full Manufacturer: MOSART Semi. Product: 2.4G Wireless Mouse Address: sysfs:/sys/devices/pci0000:00/0000:00:01.2/0000:01:00.0/usb1/1-9//device:/dev/vboxusb/001/003 Current State: Busy UUID: ba531afc-89b0-4027-a11c-c602227956dc VendorId: 0x05e3 (05E3) ProductId: 0x0743 (0743) Revision: 8.33 (0833) Port: 0 USB version/speed: 3/Super Manufacturer: Generic Product: USB Storage SerialNumber: 000000000821 Address: sysfs:/sys/devices/pci0000:00/0000:00:08.1/0000:06:00.3/usb4/4-4/4-4.1//device:/dev/vboxusb/004/003 Current State: Busy UUID: ae8f841f-253c-4074-a69f-ad6fc4e2cd15 VendorId: 0x046d (046D) ProductId: 0x081d (081D) Revision: 0.16 (0016) Port: 7 USB version/speed: 2/High Manufacturer: Logitech, Inc. Product: HD Webcam C510 SerialNumber: 4E0D4B90 Address: sysfs:/sys/devices/pci0000:00/0000:00:01.2/0000:01:00.0/usb1/1-8//device:/dev/vboxusb/001/002 Current State: Busy
Your empty usbhost list when running as a regular user is the problem. On my system, there is no difference when I run the command as root. I was hoping that would find some command that showed a lack of permissions, but no such luck. It has been a slog, but I compared your hostlist.txt with mine. The first real difference is about 60% through the file. Your system fails a connection: connect(5, {sa_family=AF_UNIX, sun_path="/tmp/.vbox-johannes-ipc/ipcd"}, 106) = -1 ECONNREFUSED (Verbindungsaufbau abgelehnt) On my system, that command succeeds. Please check the permissions on /tmp/.vbox-johannes-ipc and /tmp/.vbox-johannes-ipc/ipcd with ls -ld /tmp/.vbox-j* ls -l /tmp/.vbox-j* The first one should show a directory belonging to johannes:users as follows: drwx------ 2 johannes users 4096 Jul 28 12:36 /tmp/.vbox-johannes-ipc and the second should show two files as follows: srwx------ 1 johannes users 0 Jul 28 12:36 ipcd -rw------- 1 johannes users 5 Jul 28 12:36 lock
Hi Thanks, the output of the commands is: ohannesOffice:/home/johannes # ls -ld /tmp/.vbox-j* drwx------ 1 johannes users 16 2020-07-28 20:49 /tmp/.vbox-johannes-ipc JohannesOffice:/home/johannes # ls -l /tmp/.vbox-j* insgesamt 4 srwx------ 1 johannes users 0 2020-07-28 20:49 ipcd -rw------- 1 johannes users 6 2020-07-28 20:49 lock As far as I can see, what is expected... Thanks a lot
Yes, I did not read far enough. Your system connected about 15 lines later in the file. I did not find any place where yours failed due to permissions. If you run the command ls -l /dev/vbo* What do you get?
(In reply to Larry Finger from comment #18) > Thanks. As expected, the logs show a permissions problem. Finding why that > happens in the code gets a bit more complicated. > > Where did the VBoxSVC.log come from? I could not find that on my machine. > > What is the output of 'VBoxManage list usbhost'? If that shows nothing, then > run 'strace VBoxManage list usbhost >> host_list.txt 2>&1' and post > host_list.txt. As mentioned in my OP, in Leap 15.2 the command “VBoxManage list usbhost” also returns <none> when invoked as a user. But when it’s invoked as root, it returns a long list of USB devices. Circumstantially, this seemed to hint at a permissions problem. Beyond that, when I first installed Leap 15.2 about a month ago (fresh install, not an upgrade), I had a problem with the vboxusers group. Briefly, the VirtualBox installation, the command <groups> in a terminal and the YaST GUI all thought the vboxusers group was missing. Inconsistently, however, the command <groupadd> in a terminal and the content of the file /etc/groups thought it already existed. I posted this to the opensuse@opensuse.org list, and David Rankin suggested that I might try gpasswd -a robin vboxusers. I did, and it worked. I don’t know enough to know if this might be related to the USB difficulty in VirtualBox, but I wondered if it might be relevant in some way?
I had no problems with adding that group to my account. I used the YaST GUI. What does 'grep vbox /etc/group' show?
It shows vboxusers:x:461:robin (Part of the problem was that vboxusers was listed in /etc/group but not showing up at all as an option in the YaST GUI; yet the groupadd command returned “vboxusers already exists”. <gpasswd -a robin vboxusers> fixed all that.)
@Robin: Your problem may have been caused by YaST requiring a full exit after vboxusers is added to the group table before any user can acquire that group. Sometimes, a logout is required. Upon a closer look at hostlist.txt, there is a difference even before the strace kicks in. I need to look at that utility to see what differs in its execution. What is the output of 'ls -l /usr/lib/virtualbox/ | grep vboxusers'?
Hello, the output of the two commands is: johannes@JohannesOffice:~> grep vbox /etc/group vboxusers:x:457:johannes johannes@JohannesOffice:~> ls -l /usr/lib/virtualbox/ | grep vboxusers -rwsr-x--- 1 root vboxusers 166536 2020-07-28 00:54 VBoxHeadless -rwsr-x--- 1 root vboxusers 31360 2020-07-28 00:54 VBoxNetAdpCtl -rwsr-x--- 1 root vboxusers 166536 2020-07-28 00:54 VBoxNetDHCP -rwsr-x--- 1 root vboxusers 166536 2020-07-28 00:54 VBoxNetNAT -rwxr-xr-x 1 root vboxusers 14576 2020-07-28 00:54 VBoxPermissionMessage -rwsr-x--- 1 root vboxusers 166528 2020-07-28 00:54 VBoxSDL -rwxr-xr-x 1 root vboxusers 14576 2020-07-28 00:54 VBoxSUIDMessage -rwxr-xr-x 1 root vboxusers 14600 2020-07-28 00:54 VBoxUSB_DevRules -rwxr-xr-x 1 root vboxusers 2246640 2020-07-28 00:54 VirtualBox6 -rwsr-x--- 1 root vboxusers 166536 2020-07-28 00:54 VirtualBoxVM johannes@JohannesOffice:~ Actually I am beginning to doubt, that is is originally a vbox issue. May some other update had sideeffects on the permissions? However this would be very difficult to find out, I guess.....
The files belonging to root:vboxusers should be as follows: In /usr/lib/virtualbox/ * VBoxNetNAT * VBoxNetDHCP * VBoxNetAdpCtl * VBoxHeadless VBoxPermissionMessage VBoxSUIDMessage VBoxUSB_DevRules VirtualBox6 * VirtualBoxVM * VBoxSDL Files marked with an * are SUID. In /etc/ vbox/ vbox/vbox.cfg vbox/autostart.cfg The files under /etc are only used for autostart of VMs. On the web, the only reason listed for USB passthru failing is the user not belonging to vboxusers. Actually, the GUI will not start if that is the case. The permissions are set by the permissions package. Running sudo chkstat --system --set will ensure that they are set properly.
robin@Corgi:~> ls -l /usr/lib/virtualbox | grep vboxusers -rwsr-x--- 1 root vboxusers 158352 Jul 28 10:48 VBoxHeadless -rwsr-x--- 1 root vboxusers 27280 Jul 28 10:48 VBoxNetAdpCtl -rwsr-x--- 1 root vboxusers 158344 Jul 28 10:48 VBoxNetDHCP -rwsr-x--- 1 root vboxusers 158344 Jul 28 10:48 VBoxNetNAT -rwxr-xr-x 1 root vboxusers 10488 Jul 28 10:48 VBoxPermissionMessage -rwsr-x--- 1 root vboxusers 158344 Jul 28 10:48 VBoxSDL -rwxr-xr-x 1 root vboxusers 10480 Jul 28 10:48 VBoxSUIDMessage -rwxr-xr-x 1 root vboxusers 10512 Jul 28 10:48 VBoxUSB_DevRules -rwxr-xr-x 1 root vboxusers 2566128 Jul 28 10:48 VirtualBox6 -rwsr-x--- 1 root vboxusers 162448 Jul 28 10:48 VirtualBoxVM
One additional test: Does 'grep PERMISSION_SECURITY /etc/sysconfig/security' show PERMISSION_SECURITY="easy local" From other stuff you have posted, I think that you have "easy" selected. It is the default. Finally, have you rebooted since this problem first showed up?
(In reply to Larry Finger from comment #32) > One additional test: Does 'grep PERMISSION_SECURITY /etc/sysconfig/security' > show > PERMISSION_SECURITY="easy local" > > From other stuff you have posted, I think that you have "easy" selected. It > is the default. > > Finally, have you rebooted since this problem first showed up? Yes to the first ("easy local" confirmed) Yes to the second. Frequently.
Created attachment 840217 [details] Shell script that is supposed to fix USB problems.
I am grasping at straws now. I know a little C++, but the code in VB really strains my ability to add meaningful debugging statements. Check the permissions on /dev/bus/usb with ls -l /dev/bus/ Mine reads total 0 drwxr-xr-x 6 root root 120 Jul 29 13:01 usb In addition, check ls -l /dev/bus/usb/ There should be entries 001, 002, etc. owned by root:root with an entry for each root hub listed in 'lsusb'. One Web article suggests that USB passthru will fail if the system runs out of inotify resources. Check that with tail -f /var/log/Xorg.0.log If you get the tail of the file, that is not the problem. It has been reported that a failure will happen when vboxusers was the last line of /etc/group; however, that did not cause my system to fail. Finally, at least for now, I found a script, called check_USB.sh, that writes new udev rules for USB. That script has been uploaded to the attachments. Download it, run as root, and reboot. The new rules did not break my existing system.
Hello, applying your script (as sudo) fixed the problem. However, today there were some new updates, that I installed. After rebooting your fixes were gone... Applying again your script fixed the problem again... I will follow up. But, really, Thanks a lot for your effort... Johannes
Hello, now I rebooted again without any updates. And after reboot I again can't access USB passthrough. Seems I have to apply your script every time I have to access USB... :-) Anyway, here are the outputs from your commands: the last line in /etc/group is: users:x:100:johannes johannes@JohannesOffice:~> ls -l /dev/bus/ insgesamt 0 drwxr-xr-x 8 root root 160 2020-07-30 20:59 usb johannes@JohannesOffice:~> johannes@JohannesOffice:~> ls -l /dev/bus/usb/ insgesamt 0 drwxr-xr-x 2 root root 120 2020-07-30 20:59 001 drwxr-xr-x 2 root root 60 2020-07-30 20:59 002 drwxr-xr-x 2 root root 100 2020-07-30 20:59 003 drwxr-xr-x 2 root root 100 2020-07-30 20:59 004 drwxr-xr-x 2 root root 60 2020-07-30 20:59 005 drwxr-xr-x 2 root root 60 2020-07-30 20:59 006 johannes@JohannesOffice:~> tail -f /var/log/Xorg.0.log [ 14.429] (II) AMDGPU(0): Modeline "1024x768"x0.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz e) [ 15.715] (II) AMDGPU(0): EDID vendor "ENC", prod id 5929 [ 15.715] (II) AMDGPU(0): Using hsync ranges from config file [ 15.715] (II) AMDGPU(0): Using vrefresh ranges from config file [ 15.715] (II) AMDGPU(0): Printing DDC gathered Modelines: [ 15.715] (II) AMDGPU(0): Modeline "1280x1024"x0.0 108.00 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync (64.0 kHz eP) [ 15.715] (II) AMDGPU(0): Modeline "800x600"x0.0 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz e) [ 15.715] (II) AMDGPU(0): Modeline "640x480"x0.0 25.18 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz e) [ 15.715] (II) AMDGPU(0): Modeline "720x400"x0.0 28.32 720 738 846 900 400 412 414 449 -hsync +vsync (31.5 kHz e) [ 15.715] (II) AMDGPU(0): Modeline "1024x768"x0.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz e) ^C
One more comment: After applying the script, I logged out, I didn't reboot. After logging out and in again, with the script applied, USB works. After rebooting, USB doesn't work... But I can reapply the script. Thanks, Johannes
Created attachment 840226 [details] 2nd version of script
have been trying to understand what changes with that script. There are essentially two differences: 1. It sets the 4th argument of VBoxCreateUSBNode.sh to the numerical value of vboxusers. If that argument is blank, it sets the group to "vboxusers". That should not make a difference. 2. It changes the location of the VB udev rules to be in /etc/udev/rules.d/ instead of in /usr/lib/udev/rules.d/. If this is the critical change, then there is a bug someplace in openSUSE. The 2nd version of the script removes the change in #1. If using this script still helps, then #2 is the problem. Thanks for testing.
(In reply to Larry Finger from comment #40) > have been trying to understand what changes with that script. There are > essentially two differences: > > 1. It sets the 4th argument of VBoxCreateUSBNode.sh to the numerical value > of vboxusers. If that argument is blank, it sets the group to "vboxusers". > That should not make a difference. > > 2. It changes the location of the VB udev rules to be in /etc/udev/rules.d/ > instead of in /usr/lib/udev/rules.d/. If this is the critical change, then > there is a bug someplace in openSUSE. > > The 2nd version of the script removes the change in #1. If using this script > still helps, then #2 is the problem. > > Thanks for testing. I regret to have to report that neither of the two scripts improves things here. But thank you anyway, Larry, for the effort you've put into dealing with what seems to be a tiny minority problem - and possibly even self-inflicted. I'm very grateful.
Are either of you installing any packages from 3rd party repositories sch as Packman, etc.? My thought is that something is setting the device rules from /etc/udev rather than from /usr/lib/udev/.
Created attachment 840268 [details] Repositories
Hello, indeed, I have the Packman repository. I think I needed it for multimedia codecs.. Thanks a lot for your effort! Johannes
I forgot to write, that I have attached the Repolist in the text-file, because the line are too long and it wasn't easy to read....
Thanks for the repo list. I also have Packman enabled, and it is not causing a problem here. Since my last post, I learned more about udev. The files in both rules.d directories are executed in alphabetic order regardless of their location. The only special situation is that a file in /etc/udev/rules.d/ will override those in /usr/lib/udev/rules.d/ in case of duplicates. That does not apply here, but the new rule from the script will be applied last.
Created attachment 840270 [details] Robin_Repos.zip
Yes; I’m using Packman and others, including openSUSE/Plasma/Qt update channels from http://download.opensuse.org. My current Leap 15.2 system is at: Operating System: openSUSE Leap 15.2 KDE Plasma Version: 5.19.4 KDE Frameworks Version: 5.72.0 Qt Version: 5.15.0 Kernel Version: 5.3.18-lp152.33-default OS Type: 64-bit Processors: 8 × Intel® Core™ i7-4770 CPU @ 3.40GHz Memory: 31.3 GiB of RAM Graphics Processor: GeForce GTX 670/PCIe/SSE2 This is a multi-boot machine upon which, largely for historical reasons and curiosity but also for prudence, I maintain separate Leap 15.2, Leap 15.1 and Tumbleweed installations. Each has its own /home – non-shared; and each is always installed fresh, not as upgrades. A couple of months or so ago (before Leap 15.2) I first ran into the USB problem with VirtualBox and Win 10 in Leap 15.1, using the Oracle package, not the openSUSE ones. That Vbox setup had worked very well for several years, consistently under a succession of previous editions of Leap/openSUSE. Initially in 15.2 it worked briefly, then quit. This might indeed tend to support an idea that something from the component update repos I’m using could be the problem. As an experiment, last evening I installed Vbox into my current Tumbleweed host in the hope that Tumbleweed, being Tumbleweed, might not be prey to similar update error. But I got the same result – no USB in the Win 10 guest. For what it may be worth, I attach the output of zypper lr -e for each of these three installations. For simplicity the texts have been edited to remove several repos not held in common (or equivalent) across the three systems. If the source of the problem is an inappropriate component update, it would have to exist in all three systems.
I'm running into the same issue on tumbleweed. It doesn't seem to be an issue with the usb permissions as I can access it: $ find /dev/vboxusb/ -ls 24884 0 drwxr-x--- 5 root vboxusers 100 Sep 2 07:42 /dev/vboxusb/ 67434 0 drwxr-x--- 2 root vboxusers 40 Sep 2 07:54 /dev/vboxusb/004 5423 0 drwxr-x--- 2 root vboxusers 80 Sep 2 07:36 /dev/vboxusb/001 30883 0 crw-rw---- 1 root vboxusers 189, 1 Sep 2 07:36 /dev/vboxusb/001/002 5428 0 crw-rw---- 1 root vboxusers 189, 2 Sep 2 07:36 /dev/vboxusb/001/003 35736 0 drwxr-x--- 2 root vboxusers 120 Sep 2 07:36 /dev/vboxusb/003 39943 0 crw-rw---- 1 root vboxusers 189, 261 Sep 2 07:36 /dev/vboxusb/003/006 32041 0 crw-rw---- 1 root vboxusers 189, 260 Sep 2 07:36 /dev/vboxusb/003/005 2387 0 crw-rw---- 1 root vboxusers 189, 259 Sep 2 07:36 /dev/vboxusb/003/004 1468 0 crw-rw---- 1 root vboxusers 189, 258 Sep 2 07:36 /dev/vboxusb/003/003 $ cat /dev/vboxusb/001/002 m+$ T1 !"; !" !"b As I get output form the device, I obviously must have access via vboxusers group as a user. I tried to get more log output, but didn't really work using: export VBOX_RELEASE_LOG="rem*.e.l.f main gui" export VBOX_RELEASE_LOG_FLAGS="buffered thread msprog" mkdir /tmp/vbox export VBOXSVC_RELEASE_LOG_DEST='dir=/tmp/vbox' then starting the service manually: /usr/lib/virtualbox/VBoxSVC Then I tried to strace it. The strange thing is that printed on the commandline: <html><b>Effective UID is not root (euid=1000 egid=100 uid=1000 gid=100) (rc=-10)</b><br/><br/>Please try reinstalling VirtualBox.<br><br><!--EOM-->where: SUPR3HardenedMain what: 2 VERR_PERMISSION_DENIED (-10) - Permission denied. </html> asn $> bgrep "Effective UID" /usr/lib/virtualbox/ Effective UID is not root (euid=%d egid=%d uid=%d gid=%d) >>>>>> /usr/lib/virtualbox/VBoxHeadless Effective UID is not root (euid=%d egid=%d uid=%d gid=%d) >>>>>> /usr/lib/virtualbox/VBoxNetDHCP Effective UID is not root (euid=%d egid=%d uid=%d gid=%d) >>>>>> /usr/lib/virtualbox/VBoxNetNAT Effective UID is not root (euid=%d egid=%d uid=%d gid=%d) >>>>>> /usr/lib/virtualbox/VBoxSDL Effective UID is not root (euid=%d egid=%d uid=%d gid=%d) >>>>>> /usr/lib/virtualbox/VirtualBoxVM asn $> ll /usr/lib/virtualbox/VBoxHeadless -rwsr-x--- 1 root vboxusers 166536 Aug 29 04:21 /usr/lib/virtualbox/VBoxHeadless asn $> ll /usr/lib/virtualbox/VBoxNetDHCP -rwsr-x--- 1 root vboxusers 166528 Aug 29 04:21 /usr/lib/virtualbox/VBoxNetDHCP asn $> ll /usr/lib/virtualbox/VBoxNetNAT -rwsr-x--- 1 root vboxusers 166528 Aug 29 04:21 /usr/lib/virtualbox/VBoxNetNAT asn $> ll /usr/lib/virtualbox/VBoxSDL -rwsr-x--- 1 root vboxusers 166528 Aug 29 04:21 /usr/lib/virtualbox/VBoxSDL asn $> ll /usr/lib/virtualbox/VirtualBoxVM -rwsr-x--- 1 root vboxusers 166536 Aug 29 04:21 /usr/lib/virtualbox/VirtualBoxVM The strange thing is, those binaries all have the suid bit set.
(In reply to Andreas Schneider from comment #49) > I'm running into the same issue on tumbleweed. > > It doesn't seem to be an issue with the usb permissions as I can access it: > > $ find /dev/vboxusb/ -ls > 24884 0 drwxr-x--- 5 root vboxusers 100 Sep 2 07:42 > /dev/vboxusb/ > 67434 0 drwxr-x--- 2 root vboxusers 40 Sep 2 07:54 > /dev/vboxusb/004 > 5423 0 drwxr-x--- 2 root vboxusers 80 Sep 2 07:36 > /dev/vboxusb/001 > 30883 0 crw-rw---- 1 root vboxusers 189, 1 Sep 2 07:36 > /dev/vboxusb/001/002 > 5428 0 crw-rw---- 1 root vboxusers 189, 2 Sep 2 07:36 > /dev/vboxusb/001/003 > 35736 0 drwxr-x--- 2 root vboxusers 120 Sep 2 07:36 > /dev/vboxusb/003 > 39943 0 crw-rw---- 1 root vboxusers 189, 261 Sep 2 07:36 > /dev/vboxusb/003/006 > 32041 0 crw-rw---- 1 root vboxusers 189, 260 Sep 2 07:36 > /dev/vboxusb/003/005 > 2387 0 crw-rw---- 1 root vboxusers 189, 259 Sep 2 07:36 > /dev/vboxusb/003/004 > 1468 0 crw-rw---- 1 root vboxusers 189, 258 Sep 2 07:36 > /dev/vboxusb/003/003 > > $ cat /dev/vboxusb/001/002 > m+$ T1 !"; !" !"b > > As I get output form the device, I obviously must have access via vboxusers > group as a user. > > I tried to get more log output, but didn't really work using: > > export VBOX_RELEASE_LOG="rem*.e.l.f main gui" > export VBOX_RELEASE_LOG_FLAGS="buffered thread msprog" > mkdir /tmp/vbox > export VBOXSVC_RELEASE_LOG_DEST='dir=/tmp/vbox' > > then starting the service manually: > > /usr/lib/virtualbox/VBoxSVC > > Then I tried to strace it. The strange thing is that printed on the > commandline: > > <html><b>Effective UID is not root (euid=1000 egid=100 uid=1000 gid=100) > (rc=-10)</b><br/><br/>Please try reinstalling > VirtualBox.<br><br><!--EOM-->where: SUPR3HardenedMain > what: 2 > VERR_PERMISSION_DENIED (-10) - Permission denied. > </html> > > > asn $> bgrep "Effective UID" /usr/lib/virtualbox/ > Effective UID is not root (euid=%d egid=%d uid=%d gid=%d) > >>>>>> /usr/lib/virtualbox/VBoxHeadless > > Effective UID is not root (euid=%d egid=%d uid=%d gid=%d) > >>>>>> /usr/lib/virtualbox/VBoxNetDHCP > > Effective UID is not root (euid=%d egid=%d uid=%d gid=%d) > >>>>>> /usr/lib/virtualbox/VBoxNetNAT > > Effective UID is not root (euid=%d egid=%d uid=%d gid=%d) > >>>>>> /usr/lib/virtualbox/VBoxSDL > > Effective UID is not root (euid=%d egid=%d uid=%d gid=%d) > >>>>>> /usr/lib/virtualbox/VirtualBoxVM > > asn $> ll /usr/lib/virtualbox/VBoxHeadless > -rwsr-x--- 1 root vboxusers 166536 Aug 29 04:21 > /usr/lib/virtualbox/VBoxHeadless > asn $> ll /usr/lib/virtualbox/VBoxNetDHCP > -rwsr-x--- 1 root vboxusers 166528 Aug 29 04:21 > /usr/lib/virtualbox/VBoxNetDHCP > asn $> ll /usr/lib/virtualbox/VBoxNetNAT > -rwsr-x--- 1 root vboxusers 166528 Aug 29 04:21 > /usr/lib/virtualbox/VBoxNetNAT > asn $> ll /usr/lib/virtualbox/VBoxSDL > -rwsr-x--- 1 root vboxusers 166528 Aug 29 04:21 /usr/lib/virtualbox/VBoxSDL > asn $> ll /usr/lib/virtualbox/VirtualBoxVM > -rwsr-x--- 1 root vboxusers 166536 Aug 29 04:21 > /usr/lib/virtualbox/VirtualBoxVM > > The strange thing is, those binaries all have the suid bit set. What happens if you create a new user belonging to vboxusers? Can that account run VBox?
Is this problem still active?
Hello, it is working again as expected. No issues or problems anymore. Actually it must have started working again anytime before 2020-10-31. On this date I ckecked again if it works and it worked. I can't tell you the exact date it started working, because I didn't try before. If you need additional information, please let me know and I will try to get it. BTW, thanks for asking, I appreciate it.
No issues anymore. The exact reason is unknown to me.