freecode
Contributor
Contributor

Workstation 15.5 Pro works only as root, fails as normal user - what's up here?

Jump to solution

If I run VMWare Workstation 15.5 as root, it works fine. If I try to run it as a normal user (as it used to work), I get the following error in the terminal:

/usr/bin/vmware: line 105:  7080 Segmentation fault      (core dumped) "$BINDIR"/vmware-modconfig --appname="VMware Workstation" --icon="vmware-workstation"

Has anyone seen this before? It runs as root, but refuses to run as the normal user as it did just fine in 15.1 before.

1 Solution

Accepted Solutions
brf
Enthusiast
Enthusiast

Happened to me today after upgrading from 15.1 to 15.5, on Fedora 30.  Permissions on /etc/vmware/config ended up wrong.  Probably a bug in the 15.5 installer.  Try "chmod a+r /etc/vmware/config" and it may fix your problem.  Did for me.  (Sorry for the delete/re-post, posted from wrong account originally.)

Also, might make sense for VMware to actually produce some sane error if /etc/vmware/config isn't readable, rather than just segfaulting which is a bit ludicrous.

View solution in original post

0 Kudos
28 Replies
xishengzhang
VMware Employee
VMware Employee

Hello, Freecode

Thanks for your posting.

Did you install the Workstation 15.5 with root user or common user with "sudo" privilege? 

0 Kudos
freecode
Contributor
Contributor

Hi XS,

Thanks for the reply. I did perform the install with sudo privileges with a normal user as I had done several times before without issue. Not sure which logs to review to find the error in question, and which flags to set to log with sufficient verbosity to determine cause. Did seem to be missing libaio libraries (corrected), but the environment only runs when using sudo, whereas before, it ran by simply clicking on the icon. When running on the command line to try to determine what is happening, only see the one message about a segfault - nothing more.

If I knew what to log and how to set that, I might be able to determine root cause and find a workaround, but the various logs haven't shown an actual issue. 12 - 15.1 were installed the same way, without issue. Only 15.5 throws this error when starting.

If anyone has guidance on setting the correct logging, that might help me work it out.

Thanks again, do appreciate any insight here.

Have a nice day!

0 Kudos
iRunner2016
Enthusiast
Enthusiast

Could you please let me know your distro name and version of your host os?

0 Kudos
bryceb1234
Contributor
Contributor

I'm experiencing this as well. Here are my OS details, fwiw.

NAME="Ubuntu"

VERSION="18.04.3 LTS (Bionic Beaver)"

0 Kudos
BourbonNBeer
Contributor
Contributor

I had this issue.  VMWare has a bug.  They failed to set the permission on certain files during the install/configuration so new files get the incorrect permission.  To fix it set your umask to 0002 and reinstall and configure VMWare.

Setting umask to a more secure setting is a common ways to increase security on a Red Hat/Linux system  The installer should always set the correct permission on newly created files and not rely on the default.  Wish VMWare just used RPM or Deb packages instead.

0 Kudos
iRunner2016
Enthusiast
Enthusiast

Sorry, we cannot reproduce this issue in our environments, even with umask 077. Could you please provide more information?

1. Locale of the host.

2. Upgrading of fresh installation? If upgrading, the former version?

3. umask setting.

0 Kudos
freecode
Contributor
Contributor

Hi IRunner2016,

Thinks for your reply, in response:

The system locale:

LANG=en_US.UTF-8

LANGUAGE=en_US:en

LC_CTYPE="en_US.UTF-8"

LC_NUMERIC="en_US.UTF-8"

LC_TIME="en_US.UTF-8"

LC_COLLATE="en_US.UTF-8"

LC_MONETARY="en_US.UTF-8"

LC_MESSAGES="en_US.UTF-8"

LC_PAPER="en_US.UTF-8"

LC_NAME="en_US.UTF-8"

LC_ADDRESS="en_US.UTF-8"

LC_TELEPHONE="en_US.UTF-8"

LC_MEASUREMENT="en_US.UTF-8"

LC_IDENTIFICATION="en_US.UTF-8"

LC_ALL=

The issue was an original upgrade from 15.1 to 15.5. There were no issues in 15.1 or 15, but going to 15.5 the problem appeared. I uninstalled and have reinstalled, but this does not affect the outcome.

The umask on the instance:

0022

The current kernel is:

5.0.0-31-generic

The distribution is:

Distributor ID: Ubuntu

Description: Pop!_OS 19.04

Release: 19.04

Codename: disco

It worked without issue before, the only workaround at present is to run this with the sudo command whereas before, my user could start this up without issue from the GNOME Shell icon.

Thanks.

0 Kudos
iRunner2016
Enthusiast
Enthusiast

It seems that the settings above are nothing sepcial.

Could you please help us check the following items?

1. Launch vmware-netcfg with a non-privileged user.

2. Execute the following command in the terminal with a non-privileged user.

    vmware-modconfig --appname="VMware Workstation" --icon="vmware-workstation"

0 Kudos
freecode
Contributor
Contributor

Hi IRunner2016,

Running the commands as a non-privileged user on the system (not in sudoers file): provides the following output:

vmtest@$hostname:~$ vmware-netcfg

No protocol specified

(vmware-netcfg:827): Gtk-WARNING **: 06:34:54.173: cannot open display: :1

vmtest@$hostname:~$ vmware-modconfig --appname="VMware Workstation" --icon="vmware-workstation"

No protocol specified

(vmware-modconfig:1055): Gtk-WARNING **: 06:35:48.322: cannot open display: :1

That gave me a hint that maybe there is a missing call somewhere so I tried the following:

vmtest@$hostname:~$ vmware export DISPLAY=:1

No protocol specified

(vmware-modconfig:4191): Gtk-WARNING **: 06:50:58.843: cannot open display: :1

THen I decided to try as my regular (sudoer enabled) account and found the following:

$normalUser@$hostname:~$ vmware export DISPLAY=:1

I/O error : Permission denied

I/O error : Permission denied

I/O warning : failed to load external entity "/etc/vmware/hostd/proxy.xml"

I/O error : Permission denied

I/O error : Permission denied

I/O warning : failed to load external entity "/etc/vmware/hostd/proxy.xml"

I/O error : Permission denied

I/O error : Permission denied

I/O warning : failed to load external entity "/etc/vmware/hostd/proxy.xml"

   Starting Workstation Server:                                        done

It eventually does ask for the sudo auth, but does startup at that point going through all of the normal questions about the user, the proxy, the location of VMs, etc.

So, I suspect it is something to do with perms on the install that changed between the install of Workstation 15 and 15.1, then was altered in 15.5 as this started occurring whereas previous experience was not this way. No longer can I simply launch the VMs on the launcher icon, something behaviour wise has been altered in the installation script.

If I knew how to enable debugging on Workstation somewhere, I might find the complaining bit of information.Looking into the hostd-$number.log, I did see this:

2019-10-15T06:48:51.277-05:00 info hostd[03850] [Originator@6876 sub=Libs] HALLoadLibrary: Could not dlopen libhal.so.1: libhal.so.1: cannot open shared object file: No such file or directory.

2019-10-15T06:48:51.277-05:00 info hostd[03850] [Originator@6876 sub=Libs] HALLoadLibrary: Could not dlopen libhal.so.0: libhal.so.0: cannot open shared object file: No such file or directory.

2019-10-15T06:48:51.277-05:00 error hostd[03850] [Originator@6876 sub=Hostsvc] Failed to enumerate Pci devices

Not sure if that is informative or not.

0 Kudos
iRunner2016
Enthusiast
Enthusiast

WS 15.5 killed the UI from the installer, and move the configuration pages into the first-time dialog of the Workstation/Player itself. So, after you installed Workstation/Player, the first-time dialog to configure the product will show. When configuring WS/Player, some files owned by root need to be modified, so privilege is needed when you click "Finish" button on the dialog. But once you have completed the configurations, the first-time dialog will not show again in the next launch. Now, WS/Player can be launched without asking for privilege.

By default, policykit (pkexec) is used to get promotion.

So, as to the terminal output like "No protocol specified. Gtk-WARNING **: 06:35:48.322: cannot open display: :1", this is not related to Workstation. Because the user you launched the app is different from the user of the display server, the access control forbids the client to connect to the display server. You can use "xhost +" disable it.

0 Kudos
brf
Enthusiast
Enthusiast

Happened to me today after upgrading from 15.1 to 15.5, on Fedora 30.  Permissions on /etc/vmware/config ended up wrong.  Probably a bug in the 15.5 installer.  Try "chmod a+r /etc/vmware/config" and it may fix your problem.  Did for me.  (Sorry for the delete/re-post, posted from wrong account originally.)

Also, might make sense for VMware to actually produce some sane error if /etc/vmware/config isn't readable, rather than just segfaulting which is a bit ludicrous.

0 Kudos
freecode
Contributor
Contributor

Thanks, this lead me to find the issue within /etc/vmware/host.d/ directory for the proxy.xml file which had incorrect perms. My issue is solved. Agree it would be nice to have some actual startup logging to determine what was occurring other than the segfault message. That could help me solve issues much faster. Your answer helped me isolate and correct the actual cause.

Thanks again brf! Not exactly the same issue, but that was what lead me there.

0 Kudos
brf
Enthusiast
Enthusiast

For others, if you don't know exactly which file is causing the seg fault, you can do: strace -f vmware

Go through the output to where the segfault signal occurs, and take note of which file it was trying to open just before it happened.

For iRunner2016, even if you can't track down why files are getting wrong permissions for now, at least try doing something like "chmod o-r /etc/vmware/config" then run vmware as a regular user, see if you get the segfault on your system.  Segfaulting because you couldn't open a file is nutty, so that in itself should be considered a bug too.

iRunner2016
Enthusiast
Enthusiast

Thank you so much for your valuable information. After changing the permission of /etc/vmware/config to 600, this crash can be reproduced in our internal environment. And this failure is logged in /tmp/vmware-$USERNAME/vmware-apploader-$PID.log.

However, I cannot reproduce the scenario that the permission is set incorrectly, either fresh installation or upgrading from 15.1. On the other hand, the installer sets its own umask in the script. So, it's tricky that the permission is wrong. What's more, in @freecode's environment, the default umask is "022".

So, could you describe the details of your steps to install WS 15.5?

1. Fresh installation or upgrade from 15.1?

2. If you upgraded WS 15.5 from 15.1, which method did you use? Upgrade from WS UI or execute the bundle from terminal?

3. If you upgraded WS 15.5 by executing the bundle, which command did you use?

4. Default umask of your current user and root?
5. How did you set your umask if it is a more secure one?

6. What's the permission of file /etc/vmware/config?

0 Kudos
brf
Enthusiast
Enthusiast

Upgraded from 15.1.0 to 15.5.0 here, on Fedora 30.  Used the bundle file from the terminal, by running: sh VMware-Workstation-Full-15.5.0-14665864.x86_64.bundle

My umask is 0007 as both my regular user acct and when I'm root.  Set from ~/.bashrc.

/etc/vmware/config is 664 now, but it was 660 before I changed it.

One other thing...  After running the upgrade, I could swear it actually worked right away.  It wasn't until I rebooted later, that it stopped working, I think?  Would the VMware services that start at boot ever muck with the permissions of /etc/vmware/config?

0 Kudos
freecode
Contributor
Contributor

That is exactly what would be helpful here; the strace -f vmware command is valuable to know. Going to verify that one. The knowledge that the /tmp directory stored the failures might have helped to document as well.  KB articles from VMware or just better sharing of what and where and how to diagnose would assist in ticket deflection and ease of manual debugging.

Thanks again!

0 Kudos
bryceb1234
Contributor
Contributor

brf​ I had the same experience. It worked the first time after upgrade or reinstall. After closing the program, it no longer worked except as root/sudo.

0 Kudos
freecode
Contributor
Contributor

TBH so did I, which is what made me wonder what went wrong at first.  It's a definite issue in the 15.5 install procedure, and there needs to be some documentation that can help us debug same easily for ticket deflection.

iRunner2016
Enthusiast
Enthusiast

Thanks for your information. The scenario can be reproduced on Fedora 30. The first boot after installation is successful, and ws crashes when next launch.

As a walkaround, you can manually change the permission of the files below to 644.

/etc/vmware/config

/etc/vmware/hostd/proxy.xml

/etc/vmware/hostd/datastores.xml

/etc/vmware/hostd/authorization.xml

This issue has been tracked dev team internally.