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

[freecode]

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.

[bushmannt]

Found this thread after I fixed the problem.  I just had this problem with Workstation 15.5 on RHEL7.5.  I tried with umask of 0077, 0027 and it would not work.  Umask of 0002 finally installs the /etc/vmware/entries with permissions that enable non-root operation without segfaulting.

VMWare, please control your install script's permissions/ownerships/umasks.  Relying on everyone to have a very lousy 0002 is a bad bet to make

[Journyman16]

None of my attempts to install and use vmware 15.5 have created a host.d directory so there is no proxy.xml. This causes vm tools to fail every time and keeps it greyed out in the menu so can't be installed manually.

There seems to also be a problem with the VM install itself - there is literally no possible way to delete a VM or even a greyed out option for it. The only way is to uninstall vmware and then physically delete the folders created for the VM location.

EDIT: I tried the strace option above and got...

root@Ringworld:/etc# strace -f /etc/vmware

execve("/etc/vmware", ["/etc/vmware"], 0x7ffe02674968 /* 27 vars */) = -1 EACCES (Permission denied)

fstat(2, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0

write(2, "strace: exec: Permission denied\n", 32strace: exec: Permission denied

) = 32

getpid()                                = 22229

exit_group(1)                           = ?

+++ exited with 1 +++

root@Ringworld:/etc#

[Journyman16]

[quote]

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.[/quote]

Unfortunately the installation on Linux Mint 19.1 does not create any host.d folder so no files to change perms on...

Any advice on what to try?

[iRunner2016]

There's no directory named "hostd.d". The directory name is "hostd", without dot between "t" and "d". Could you please check again?

[Journyman16]

My bad... It does say hostd in the error. But there is no hostd either so can't be a 'proxy.xml' to change permissions on as suggested.

markmcd@Ringworld:~$ vmplayer

[AppLoader] Use shipped Linux kernel AIO access library.

An up-to-date "libaio" or "libaio1" package from your system is preferred.

[AppLoader] Use shipped Linux kernel AIO access library.

An up-to-date "libaio" or "libaio1" package from your system is preferred.

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

(vmplayer:7104): Gtk-WARNING **: 09:11:11.675: Inserting action group 'Base' into UI manager which already has a group with this name

(vmplayer:7104): Gtk-WARNING **: 09:11:11.675: Inserting action group 'WindowActions' into UI manager which already has a group with this name

Trying to Open a previous created VM causes empty this folder to be created. Closing the VMPlayer and reopen and folder isn't there until you again try to open the VM.

Windows 7 x64.vmx.lck

I've tried the umask solutions, setting umask to both 0002 and 0007 as usggested elsewhere and for both my user and root. No change.

Double-click on the actual client .vmx file opens the client.

VMware Tools is not available in the VMPlayer even when a download happens as the client is starting. Also the VMPlayer has no option to delete client machines, which seems odd.

Linux Mint 19 Tara.

VMware-Player-15.5.0-14665864.x86_64.bundle

Virtualisation is active in BIOS. AMD CPU/MBoard.

strace =

root@Ringworld:/etc# strace -f /etc/vmware

execve("/etc/vmware", ["/etc/vmware"], 0x7ffd58b5b238 /* 27 vars */) = -1 EACCES (Permission denied)

fstat(2, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0

write(2, "strace: exec: Permission denied\n", 32strace: exec: Permission denied

) = 32

getpid()                                = 19915

exit_group(1)                           = ?

+++ exited with 1 +++

Any suggestions would be welcome.

EDIT: Given the thread says "Solved" should I open a new thread for this or is it OK here?

[brf]

First, you're using strace wrong, you should be running an "strace -f" on /usr/bin/vmware or /usr/bin/vmplayer, not /etc/vmware.

But second, not sure your problem is the same as what this thread is about.  Are you getting a segmentation fault when trying to launch vmware as a regular user?  Doesn't sound like it.

[Journyman16]

First, you're using strace wrong, you should be running an "strace -f" on /usr/bin/vmware or /usr/bin/vmplayer, not /etc/vmware.

But second, not sure your problem is the same as what this thread is about.  Are you getting a segmentation fault when trying to launch vmware as a regular user?  Doesn't sound like it.

Second - I think you are correct, which is why I asked.

First, thanks... using /usr/bin/vmplayer gives several thousand lines of text. So far I haven't figured out how to parse that to a text file. Or how to filter or truncate it. Bit of a newb to Linux which is why I want the Win VM. :smileygrin:

[brf]

strace prints to stderr not stdout, so if you wanted to capture the output to a file, you could do something like:

strace -f /usr/bin/vmware >/tmp/log 2>&1

[Journyman16]

That strace command didn't do anything - maybe Linux Mint is different in implementation?

However I removed vmware and then ran the install and start up - the logs for both root and me are attached... Hope somenoe can make sense of them. There are failures in the vmware-vmis-17795.log which seems to be the 1st to be recorded.