vmware
Installing open-vm-tools in Slackware Linux 15.0 in a virtual machine using VMware Workstation 17 Pro
Describe the bug
VMware Workstation 17 Pro version - 17.0.1 build-21139696 Slackware Linux 15.0 - kernel version - 5.15.94 open-vm-tools installed version - 12.2.0-21223074 Reference Post - github.com/vmware/open-vm-tools/issues/150
I am a retired Mac/Windows programmer, with about 40 years of experience working on computers, who is using Linux for the first time. I have been using Slackware Linux 15.0 for about two weeks now. What I am trying to determine is exactly how the open-vm-tools software should be installed on Slackware Linux 15.0 running in a virtual machine environment using VMware Workstation 17 Pro application.
The first question I have is regarding vmtoolsd. Currently I am using the command:
/usr/bin/vmtoolsd -b /var/run/vmtoolsd.pid
to start up the vmtoolsd daemon. I have put this command into the rc.local shell script located in /etc/rc.d so that the vmtoolsd daemon is started up automatically.
(1) Is this how the developers of open-vm-tools are expecting the vmtools daemon to be started in Linux? Is putting the command in rc.local shell script “correct”?
(2) What is the purpose of this vmtoolsd daemon? From the Reference Post above I saw a statement that this daemon is responsible for “power options” whatever they are. I know there are shell scripts relating to power located in /etc/vmware-tools, but I don't understand their purpose or even when they would be invoked.
Next is the problem I ran into was with the open-vm-tools.SlackBuild script that I downloaded from Slackbuilds.org. Below is a snippet from the SlackBuild script:
Original
autoreconf -i
CFLAGS="$SLKCFLAGS"
CXXFLAGS="$SLKCFLAGS"
LIBS=-lcrypt
./configure
--prefix=/usr
--libdir=/usr/lib${LIBDIRSUFFIX}
--sysconfdir=/etc
--localstatedir=/var
--mandir=/usr/man
--docdir=/usr/doc/$PRGNAM-$VERSION
--with-pam
--without-x
$VGAUTH_OPTS
--build=$ARCH-slackware-linux
Modified
autoreconf -i
CFLAGS="$SLKCFLAGS"
CXXFLAGS="$SLKCFLAGS"
LIBS=-lcrypt
./configure
--prefix=/usr
--libdir=/usr/lib${LIBDIRSUFFIX}
--sysconfdir=/etc
--localstatedir=/var
--mandir=/usr/man
--docdir=/usr/doc/$PRGNAM-$VERSION
--without-pam
--with-x
$VGAUTH_OPTS
--build=$ARCH-slackware-linux
I made two changes to the build configurations. I changed --with-pam to --without-pam. I read that pam support is not necessary for open-vm-tools. Not sure if this change is correct.
The second change is mandatory if you want copy&paste and drag&drop functionality to be available. I changed --without-x to --with-x. If you don’t make this change to the SlackBuild script, the package shown below that is produced by the SlackBuild build script, located in the /tmp directory, will not contain the necessary files for starting up the vmusr service, which is required for the copy&paste and drag&drop functionality to work.
open-vm-tools-12.2.0-21223074-x86_64-2_SBo.tgz
If the --without-x configuration is used instead of the --with-x configuration, the built package will not contain the /etc/xdg/autostart/vmware-user.desktop file nor will the built package contain the /usr/bin/vmware-user-suid-wrapper file. With these two files missing the vmusr service cannot be invoked. I don’t understand why the --without-x is the default setting. I don’t know if this is a bug or if this is what the author of the script intended. This highlights an example of myself not having enough experience with Linux to know if this is a mistake by the programmer or if there is a technical reason for having the build script configured in this fashion.
According to the Reference Post above, the vmware-user-suid-wrapper file needs to have the suid permission set using the command below. I am assuming that this is correct since “suid” is in the name of the file. Even though it seems apparent, I will still ask if changing the permission of the vmware-user-suid-wrapper is correct?
chmod u+s /usr/bin/vmware-user-suid-wrapper
The last piece of the puzzle is the one I am completely confused about. It has to do with mounting the shared folder. In the Reference Post the command below is used to mount the shared volume. This command does not seem to work on Slackware Linux.
/usr/bin/vmware-vmblock-fuse -o subtype=vmware-vmblock,default_permissions,allow_other /var/run/vmblock-fuse
The command I used, instead of the one above, is the command recommended at the very end of a KB article - kb.vmware.com/s/article/60262. I put this command line into the fstab file so that the shared folder would be mounted during startup.
.host:/ /mnt/hgfs fuse.vmhgfs-fuse defaults,allow_other 0 0
What I am confused about is why this software would rely on the user (that user would be myself in this case) to stumble upon a KB article that would explain how to mount the shared folder. If putting the above line into the fstab file is indeed how the developers intended for the shared folder to be mounted, then why isn’t there some type of documentation on the Github webpage at least pointing to the KB article so that the users of the open-vm-tools software are not totally clueless on how to completely install this software.
Installation Summary:
(1) Go to Slackbuilds.org. Download and build the two dependencies for open-vm-tools: libmspack, libdnet. If you want to have VGAUTH support you would also need to build these dependencies as well: xml-security-c, xerces-c, and xmlsec.
(2) From the Slackbuilds website download the open-vm-tools SlackBuild package and untar it.
(3) Go to Github website and download the latest version of open-vm-tools.
(4) Modify the SlackBuilds shell script as mentioned above and change the VERSION parameter in the SlackBuild shell script to reflect the build number of the file downloaded from the Github website for open-vm-tools.
(5) Build open-vm-tools using the SlackBuild shell script, then use installpkg command to install the open-vm-tools package that was built in the /tmp directory.
(6) If the build process was performed correctly you should now have all the pieces in place for copy&paste and drag&drop to work once you add the necessary commands to various locations, which I will describe next.
(7) If you want to you can go into the /etc/rc.d directory and make the rc.vmtoolsd shell script executable. This shell script can be used to stop and start the vmtoolsd daemon. I don't know if the purpose of this shell script is to be used manually to stop and start the vmtoolsd daemon or if it was intended to be use in some other manner. The fact the shell script isn't already made executable in the build process is suspicious and makes me think there might have been some other use in mind for the script by the developers. Is this what the developers intended?
(8) The vmtoolsd daemon doesn't run automatically at startup unless the command below is put into /etc/rc.d/rc.local shell script. Is this what the developers intended?
/usr/bin/vmtoolsd -b /var/run/vmtoolsd.pid
(9) The installpkg command should have installed the vmware-user.desktop file, a desktop configuration file, into the /etc/xdg/autostart directory. Check to make sure that this file is in the autostart directory. At startup the vmware-user.desktop file executes the vmware-user-suid-wrapper file, located in the /usr/bin directory, which launches the vmusr service that is needed for the copy&paste and drag&drop functionality to work.
(10) Finally, copy the line below into the /etc/fstab file in order to mount the shared folder at startup. This step is only necessary if you have enabled the VMware Workstation Pro application to use the shared folder functionality. Is this what the developers intended?
.host:/ /mnt/hgfs fuse.vmhgfs-fuse defaults,allow_other 0 0
Reproduction steps
See description.
Expected behavior
The submission of this information is not really a bug report or a feature request. It is a submission to get feedback to verify if I have installed the open-vm-tools software in a manner that is consistent with what the developers intended. If I have made a mistake in the installation process, I would like to know what I have done wrong and what to do to correct the mistake.
Additional context
No response
@thunter913
Thanks for trying out open-vm-tools, and thanks for your questions.
Starting with your first few questions for now.
The first question I have is regarding vmtoolsd. Currently I am using the command:
/usr/bin/vmtoolsd -b /var/run/vmtoolsd.pid
to start up the vmtoolsd daemon. I have put this command into the rc.local shell script located in /etc/rc.d so that the vmtoolsd daemon is started up automatically.
(1) Is this how the developers of open-vm-tools are expecting the vmtools daemon to be started in Linux? Is putting the command in rc.local shell script “correct”?
I don't know Slackware, but this is probably not correct. vmtoolsd is a system service, and setting it up to run depends on how the OS on which it's being installed configures system services. From a brief look on the internet, it seems Slackware uses the BSD-style init system. See, e.g.,
- https://unix.stackexchange.com/questions/446789/how-to-add-service-to-run-at-boot-on-slackware-linux
- https://docs.slackware.com/howtos:slackware_admin:service
These links are both a few years old, so you may want to find something more recent to confirm.
Here's some info on BSD service configuration:
- http://man.hubwiz.com/docset/FreeBSD_Hand.docset/Contents/Resources/Documents/configtuning-rcd.html
But again you'll want to do your own research to confirm this.
(2) What is the purpose of this vmtoolsd daemon? From the Reference Post above I saw a statement that this daemon is responsible for “power options” whatever they are. I know there are shell scripts relating to power located in /etc/vmware-tools, but I don't understand their purpose or even when they would be invoked.
See https://github.com/vmware/open-vm-tools/blob/master/README.md for the purpose of vmtools in general.
Further details are available in https://docs.vmware.com/en/VMware-Tools/12.0.0/vmware-tools-administration-guide.pdf. The first section "Introduction to VMware Tools" would probably be of most interest. Search for the phrase "VMware Tools Daemon Service" for specific information about the vmtoolsd daemon.
The power scripts are invoked as needed by the vmtoolsd daemon in response to power changes for the VM. See "powerOps" under VMware Tools Daemon Service in the above link. However, this is probably a level of detail you don't need to worry about.
Next is the problem I ran into was with the open-vm-tools.SlackBuild script that I downloaded from Slackbuilds.org. Below is a snippet from the SlackBuild script:
Original
autoreconf -i CFLAGS="$SLKCFLAGS" CXXFLAGS="$SLKCFLAGS" LIBS=-lcrypt ./configure --prefix=/usr --libdir=/usr/lib${LIBDIRSUFFIX} --sysconfdir=/etc --localstatedir=/var --mandir=/usr/man --docdir=/usr/doc/$PRGNAM-$VERSION --with-pam --without-x $VGAUTH_OPTS --build=$ARCH-slackware-linux
Modified
autoreconf -i CFLAGS="$SLKCFLAGS" CXXFLAGS="$SLKCFLAGS" LIBS=-lcrypt ./configure --prefix=/usr --libdir=/usr/lib${LIBDIRSUFFIX} --sysconfdir=/etc --localstatedir=/var --mandir=/usr/man --docdir=/usr/doc/$PRGNAM-$VERSION --without-pam --with-x $VGAUTH_OPTS --build=$ARCH-slackware-linux
I made two changes to the build configurations. I changed --with-pam to --without-pam. I read that pam support is not necessary for open-vm-tools. Not sure if this change is correct.
Have you tried contacting the script maintainer / contributor?
Does Slackware authentication use PAM? If so, then I would be inclined to build vmtoolsd with PAM; if not, then without. But mainly I'd check with Slackware folks, and in particular the contributor(s) of the open-vm-tools build script.
I was able to locate an open-vm-tools 11.0.5 for SlackWare Linux 14.2 at https://slackware.pkgs.org/14.2/slackpack-x86_64/open-vm-tools-11.0.5_15389592-x86_64-1gds.txz.html
You maybe able to use or adapt the vmtoolsd system service start-up from that older package.
@jonathanvmw, thanks for taking the time to reply.
After reading through the articles you referenced above, I believe you are correct that adding /usr/bin/vmtoolsd -b /var/run/vmtoolsd.pid in this form to rc.local shell script is wrong. Also, I believe I now understand how the rc.vmtoolsd shell script is really supposed to be used.
You need to set the executable permission on the rc.vmtoolsd shell script, which I had already done, then put the code below into a script that when executed, will launch the vmtoolsd daemon at startup.
if [ -x /etc/rc.d/rc.vmtoolsd ]; then /etc/rc.d/rc.vmtoolsd start fi
What still isn’t clear to me is where the above code should reside. If you look at the excerpt below, taken from inittab, there are system shell scripts that run under different conditions.
System initialization (runs when system boots). si:S:sysinit:/etc/rc.d/rc.S
Script to run when going single user (runlevel 1). su:1S:wait:/etc/rc.d/rc.K
Script to run when going multi user. rc:2345:wait:/etc/rc.d/rc.M
Adding the code above to the rc.S, rc.K, or rc.M seems wrong. This “might” be the correct, but with my limited Slackware Linux experience I am very unsure about when you are supposed to modify files that are related to the operating system.
To recap I have removed the code below from the rc.local shell script.
/usr/bin/vmtoolsd -b /var/run/vmtoolsd.pid
and replaced it with the following code, still residing in the rc.local script.
if [ -x /etc/rc.d/rc.vmtoolsd ]; then /etc/rc.d/rc.vmtoolsd start fi
@jonathanvmw
Ok, I believe the response made by bassmadrigal in a Slackware forum post confirms the changes I have made to the rc.local shell script as stated in my previous post.
https://www.linuxquestions.org/questions/slackware-14/what-is-the-proper-way-to-start-services-on-boot-4175546465/
@jonathanvmw
If the rc.local shell script is now correct that leaves two remaining pieces to the puzzle not yet answered.
(1) Can you confirm that vmware-user-suid-wrapper file needs to have the suid permission set? I know this seems obvious because “suid” is in the file name, but I will say again, due to my lack of experience with Slackware Linux I cannot make any kind of assumptions.
(2) Is the command below that I added to the fstab file in order to mount the shared folder at startup the correct command to use and is this really how the developers expect the shared folder to be mounted by placing a command in the fstab file?
.host:/ /mnt/hgfs fuse.vmhgfs-fuse defaults,allow_other 0 0
It just seems so bizarre to me that this is really how the developers intended for the shared folder to be mounted. What the developers did for vmware-user-suid-wrapper by creating the /etc/xdg/autostart/vmware-user.desktop file, which executes vmware-user-suid-wrapper is what I thought they would have done by creating something like a file called /etc/xdg/autostart/vmware-vmhgfs.desktop and had that file execute a program that mounted the shared folder.
@thunter913
A quick follow-up to my previous post - A colleague pointed out that if you're building without pam, then configure will disable vgauth (see https://github.com/vmware/open-vm-tools/blob/master/open-vm-tools/configure.ac#L636), so it doesn't seem to make sense to include both --without-pam and $VGAUTH_OPTS on the configure command line.
Continuing with responses to your first post:
The second change is mandatory if you want copy&paste and drag&drop functionality to be available. I changed --without-x to --with-x. If you don’t make this change to the SlackBuild script, the package shown below that is produced by the SlackBuild build script, located in the /tmp directory, will not contain the necessary files for starting up the vmusr service, which is required for the copy&paste and drag&drop functionality to work.
open-vm-tools-12.2.0-21223074-x86_64-2_SBo.tgz
If the --without-x configuration is used instead of the --with-x configuration, the built package will not contain the /etc/xdg/autostart/vmware-user.desktop file nor will the built package contain the /usr/bin/vmware-user-suid-wrapper file. With these two files missing the vmusr service cannot be invoked. I don’t understand why the --without-x is the default setting. I don’t know if this is a bug or if this is what the author of the script intended. This highlights an example of myself not having enough experience with Linux to know if this is a mistake by the programmer or if there is a technical reason for having the build script configured in this fashion.
This is another area where you would have to check with the Slackware developer who provided the script. --with-x is the default for configure and what you would get if you follow the instructions given in the open-vm-tools README.md file.
According to the Reference Post above, the vmware-user-suid-wrapper file needs to have the suid permission set using the command below. I am assuming that this is correct since “suid” is in the name of the file. Even though it seems apparent, I will still ask if changing the permission of the vmware-user-suid-wrapper is correct?
chmod u+s /usr/bin/vmware-user-suid-wrapper
Yes, that is correct.
The last piece of the puzzle is the one I am completely confused about. It has to do with mounting the shared folder. In the Reference Post the command below is used to mount the shared volume. This command does not seem to work on Slackware Linux.
/usr/bin/vmware-vmblock-fuse -o subtype=vmware-vmblock,default_permissions,allow_other /var/run/vmblock-fuse
The command I used, instead of the one above, is the command recommended at the very end of a KB article - kb.vmware.com/s/article/60262. I put this command line into the fstab file so that the shared folder would be mounted during startup.
.host:/ /mnt/hgfs fuse.vmhgfs-fuse defaults,allow_other 0 0
What I am confused about is why this software would rely on the user (that user would be myself in this case) to stumble upon a KB article that would explain how to mount the shared folder. If putting the above line into the fstab file is indeed how the developers intended for the shared folder to be mounted, then why isn’t there some type of documentation on the Github webpage at least pointing to the KB article so that the users of the open-vm-tools software are not totally clueless on how to completely install this software.
An internal bug has been filed about documenting this as well as the suid step.
@thunter913
Ok, I believe the response made by bassmadrigal in a Slackware forum post confirms the changes I have made to the rc.local shell script as stated in my previous post.
I'd be a little cautious as that post is a bit old, and my understanding is that this isn't how this works on BSD.
Did you look at the open-vm-tools for slackware package mentioned by johnwvmw yesterday (https://slackware.pkgs.org/14.2/slackpack-x86_64/open-vm-tools-11.0.5_15389592-x86_64-1gds.txz.html)? It may show you how they handled that. Also, it provides a contact for the person who did the packaging so you might be able to get some more information about it from them.
I took a quick look at that package, and it also has an updated build script that leave the options for x and pam unspecified, which implies that it was building with the defaults of --with-x and --with-pam.
@jonathanvmw
After reading johnwvmw post yesterday I did take a look at two Slackware packages from slackware.pkgs.org, one from 14.2 distribution as johnwvmw suggested and as well as one for a 15.0 distribution. Both of these links below are from the SlackPack mirror.
https://slackware.pkgs.org/14.2/slackpack-x86_64/open-vm-tools-11.0.5_15389592-x86_64-1gds.txz.html https://slackware.pkgs.org/15.0/slackpack-x86_64/open-vm-tools-12.1.5_20735119-x86_64-1gds.txz.html
I don't have a Slackware 14.2 virtual machine installed at the moment so I am going to try to install the 15.0 version from SlackPack on a clone of my Slackware Linux 15.0 virtual machine. This 15.0 package from SlackPack is a slightly older version (12.1.5_20735119) of open-vm-tools than from the open-vm-tools version (12.2.0-21223074) I built and installed using the SlackBuild script from the SlackBuilds mirror. The open-vm-tools 12.2.0-21223074 package was downloaded from GitHub and I changed the VERSION parameter from 11.3.5_18557794 to 12.2.0-21223074 in the SlackBuild script.
I will let you know if I am able to install the SlackPack 15.0 open-vm-tools package successfully and if the configuration is different from what I saw after building and installing the open-vm-tools package from SlackBuilds mirror.
What I mean by configuration is that after running installpkg on the package that the SlackBuild script built and rebooting, the open-vm-tools software was completely non operational. This was true even after changing the configuration setting in the SlackBuild script from --without-x to --with-x. Obviously with the configuration setting set to --without-x, the pieces needed to implement the open-vm-tools functionality were missing. Even with the --with-x change to configuration setting made, the installation of the package built by the SlackBuild script only put the pieces into place. None of the functionality was available, such as copy&paste and drag&drop, or the shared folder being mounted until I made configuration changes.
The SlackBuild script is not structured in a way that allows the installpkg to deploy a configuration on Slackware Linux that allows for functionality of open-vm-tools software to be fully available upon rebooting.
The fact that the open-vm-tools software did not work after installation is the reason why I posted to GitHub open-vm-tools issues to try and confirm if the changes I made to the SlackBuild build script and the configurations changes I made to things like rc.local and fstab were correct. Even though the open-vm-tools software is now working on my virtual machine due to the configuration changes I have made, some of those changes may not be correct as has been shown from our previous discussions above.
@jonathanvmw
The first entry below is from the SlackPack mirror. This entry is the open-vm-tools I told you I was going to install from my previous post. As you can see below only copy&paste, drag&drop were operational upon rebooting and only one vmware process was running.
The second entry is the open-vm-tools install is the only entry I have made the configuration changes on. Out of the 5 Linux installs of open-vm-tools, this is the only version that has all of the functionality fully operational. I am not sure if everything is configured “correctly”, but at least everything appears to be working.
The third entry is the VMware Tools software I installed after installing Slackware Linux. I was never able to get copy&paste, drag&drop operational because of the libdndcp.so not loading. I tried making changes to the libdndcp.so with patchelf and tried adding paths to LD_LIBRARY_PATH to see if I could make libdndcp.so be able to be loaded, but all efforts failed. This is another example of where not having enough Linux experience hinders my ability to determine if something like patchelf could fix this issue of if this is something that cannot be fixed without recompiling the software.
The fourth entry is the open-vm-tools install is on Linux Mint. The integration of open-vm-tools into the installation of Linux Mint did not produce a result where the software would be functional without user interaction.
The fifth entry is the open-vm-tools install is on Ubuntu. The integration of open-vm-tools into the installation of Ubuntu did not produce a result where the software would be functional without user interaction.
In conclusion, I really don’t understand what the intent of the developers is regarding the installation of open-vm-tools software. If their intent for the software, once installed, either being built and installed by a distribution like Slackware Linux or by being integrated into the installation of distributions like Mint and Ubuntu, is to it be fully functional with copy&paste, drag&drop, the shared folder mounted, along with any file permissions that need to be set on files that are accessed during the startup process, and launching all the necessary processes to support other functionality such as the Power scripts without any changes being implemented by the user, then this software is severely failing to function as the developers intended.
(1) Slackware Linux 15.0 Kernel - Linux 5.15.94 (x86_64) VMware Tools daemon - version 12.1.5.39265 (build-20735119)
Notes - Manually installed open-vm-tools. No configuration or file changes were made. Upon rebooting copy&paste, drag&drop were operational, but shared folder was NOT mounted.
Processes running after computer reboot: root 1312 0.1 0.4 279000 39032 ? Sl 19:51 0:00 /usr/bin/vmtoolsd -n vmusr
(2) Slackware Linux 15.0 Kernel - Linux 5.15.94 (x86_64) VMware Tools daemon - version 12.2.0.41219 (build-21223074)
Notes - Manually installed open-vm-tools. Configuration and file changes were made. The files rc.vmtoolsd and vmware-user-suid-wrapper had permission changes, the file rc.local had code added to it to launch vmtoolsd at startup, the file fstab had a configuration line added to the file in order for the shared folder to be mounted. Upon rebooting copy&paste, drag&drop were operational, and the shared folder was mounted. Not sure why there are two processes running vmhgfs-fuse, unless the line I added in the fstab file is executed twice.
Processes running after computer reboot: root 833 0.0 0.0 165420 1200 ? Ssl 21:46 0:00 vmhgfs-fuse .host:/ /mnt/hgfs -o rw,allow_other,dev,suid root 1071 0.0 0.0 165420 1204 ? Ssl 21:46 0:00 vmhgfs-fuse .host:/ /mnt/hgfs -o rw,allow_other,dev,suid root 1153 0.0 0.0 158428 6580 ? Sl 21:46 0:00 /usr/bin/vmtoolsd root 1359 1.0 0.4 278960 38704 ? Sl 21:46 0:00 /usr/bin/vmtoolsd -n vmusr
(3) Slackware Linux 15.0 Kernel - Linux 5.15.94 (x86_64) VMware Tools daemon - version 10.3.25.1451 (build-20206839)
Notes - Manually installed VMware Tools. This is not the open source open-vm-tools software. No configuration or file changes were made. Upon rebooting copy&paste, drag&drop were NOT operational, and the shared folder was mounted. The reason why copy&paste, drag&drop will NEVER work in Slackware 15.0 is because libdndcp.so library dependencies cannot be loaded. The libdndcp.so has three shared object libraries that it cannot find. You will see in the vmware-vmusr.log file the following entry - [ warning] [vmtoolsd] Loading of library dependencies for libdndcp.so failed. If you use the ldd command below you will see the following output:
ldd libdndcp.so | grep "not found" libiconv.so.2 => not found libvmtools.so => not found libhgfs.so => not found
Processes running after computer reboot:
root 1796 0.0 0.0 327824 896 ? Ssl 20:46 0:00 /usr/bin/vmhgfs-fuse -o subtype=vmhgfs-fuse,allow_other /mnt/hgfs root 1823 0.0 0.0 168720 764 ? Ssl 20:46 0:00 /usr/sbin/vmware-vmblock-fuse -o subtype=vmware-vmblock,default_permissions,allow_other /var/run/vmblock-fuse root 1831 0.0 0.2 112936 17624 ? S 20:46 0:02 /usr/lib/vmware-tools/sbin64/vmtoolsd -n vmusr --blockFd 4 root 1857 0.0 0.1 142984 8476 ? Sl 20:46 0:02 /usr/sbin/vmtoolsd root 1893 0.0 0.1 41404 11812 ? S 20:46 0:00 /usr/lib/vmware-vgauth/VGAuthService -s
(4) Linux Mint 21.1 Kernel - Linux 5.15.0-56-generic (x86_64) VMware Tools daemon - version 11.3.5.31214 (build-18557794)
Notes - open-vm-tools was integrated into of the Linux Mint install and was not manually installed. No configuration or file changes were made. Upon rebooting copy&paste, drag&drop were operational, but shared folder was NOT mounted.
Processes running after computer reboot: root 744 0.1 0.1 243736 8764 ? Ssl 19:53 0:00 /usr/bin/vmtoolsd root 1526 0.3 0.4 318928 36732 ? Sl 19:53 0:00 /usr/bin/vmtoolsd -n vmusr --blockFd 3
(5) Ubuntu 22.04.2 LTS Kernel - Linux 5.19.0-35-generic (x86_64) VMware Tools daemon, version 12.1.0.37487 (build-20219665)
Notes - open-vm-tools was integrated into of the Ubuntu install and was not manually installed. No configuration or file changes were made. Upon rebooting copy&paste was operational, drag&drop was NOT operational, and shared folder was NOT mounted. I am not sure what is going on with drag&drop. The dock seems to be interfering with drag&drop, but I am not really sure what the problem is.
Processes running after computer reboot: root 404 0.0 0.0 152560 288 ? Ssl Mar25 0:00 vmware-vmblock-fuse /run/vmblock-fuse -o rw,subtype=vmware-vmblock,default_permissions,allow_other,dev,suid root 546 0.0 0.1 178556 8452 ? Ssl Mar25 0:06 /usr/bin/vmtoolsd root 5039 0.0 0.4 371500 38860 ? Sl Mar25 0:06 /usr/bin/vmtoolsd -n vmusr --blockFd 3 --uinputFd 4
@thunter913
In conclusion, I really don’t understand what the intent of the developers is regarding the installation of open-vm-tools software. If their intent for the software, once installed, either being built and installed by a distribution like Slackware Linux or by being integrated into the installation of distributions like Mint and Ubuntu, is to it be fully functional with copy&paste, drag&drop, the shared folder mounted, along with any file permissions that need to be set on files that are accessed during the startup process, and launching all the necessary processes to support other functionality such as the Power scripts without any changes being implemented by the user, then this software is severely failing to function as the developers intended.
It is not the intent that open-vm-tools as delivered to github can be installed on any Linux distro as is and "just work". There are variations among Linux distros as to how vmtools is integrated. There is not a "one size fits all" solution for that problem; distro-specific work is needed.
My impression is that, other than resolution of the internal doc bug that was filed, the problems you were having getting open-vm-tools installed on Slackware have been addressed. If that's not the case, please clarify.
If you want help with any of the other problems mentioned in your last post (e.g., drag and drop not working on Ubuntu), please file new issues.
Thanks.