vmware
Shared Folder incorrect modify date and times (Windows 10 NTFS volume to a Linux Guest)
Describe the bug
When using Shared Folders from a Windows 10 host on an NTFS volume to a Kali Linux Guest, the modify date is incorrect or missing. This functionality previously worked using the older vmware-tools install.
uname -a
Linux k 6.8.11-amd64 #1 SMP PREEMPT_DYNAMIC Kali 6.8.11-1kali2 (2024-05-30) x86_64 GNU/Linux
cat /etc/*release*
PRETTY_NAME="Kali GNU/Linux Rolling"
NAME="Kali GNU/Linux"
VERSION_ID="2024.2"
VERSION="2024.2"
VERSION_CODENAME=kali-rolling
ID=kali
ID_LIKE=debian
HOME_URL="https://www.kali.org/"
SUPPORT_URL="https://forums.kali.org/"
BUG_REPORT_URL="https://bugs.kali.org/"
ANSI_COLOR="1;31
dpkg -l | grep open-vm
ii open-vm-tools 2:12.4.0-1 amd64 Open VMware Tools for virtual machines hosted on VMware (CLI)
ii open-vm-tools-desktop 2:12.4.0-1 amd64 Open VMware Tools for virtual machines hosted on VMware (GUI)
# /etc/fstab
.host:/backup /mnt/hgfs/backup fuse.vmhgfs-fuse allow_other,uid=0,gid=0,nofail,auto_unmount,defaults 0 0
Reproduction steps
cd /mnt/hgfs/backup/
touch time_test01
echo "test" >> time_test02
touch time_test03
ls -la
Output (Note the date on time_test01 and time_test03:
-rwxrwxrwx 1 root root 0 Dec 31 1969 time_test01
-rwxrwxrwx 1 root root 5 Jun 14 18:05 time_test02
-rwxrwxrwx 1 root root 5 Dec 31 1969 time_test03
Expected behavior
Correct modify times as it worked previously on older vmware-tools install.
Additional context
No response
Thanks for reporting, Can you elaborate on where your Shared Folder "backup" redirects to on your host? I want to replicate the same env as best I can to verify this. Thanks.
Ok, I can reproduce this issue using 12.3.5 VMware Tools in Ubuntu 22.04. I will file an internal bug and see if we can get resource and time to address this. The host file times look to be unset modified times. The creation and access times looks to be okay.
@lousybrit Thanks for the reply. Glad you were able to replicate.
It appears that Access, Modify, and Change are all unset for me:
cd /mnt/hgfs/backup/
touch time_test01
stat time_test01
File: time_test01
Size: 0 Blocks: 0 IO Block: 1024 regular empty file
Device: 0,38 Inode: 31306 Links: 1
Access: (0700/-rwx------)
Access: 1969-12-31 19:00:01.000000000 -0500
Modify: 1969-12-31 19:00:01.000000000 -0500
Change: 1969-12-31 19:00:01.000000000 -0500
Birth: -
Same file viewed from the host:
On an older Kali Rolling install with old vm-tools (same drive): All file info is correct
cd /mnt/hgfs/backup/
touch time_test-old_vm_tools
stat time_test-old_vm_tools
File: time_test-old_vm_tools
Size: 0 Blocks: 0 IO Block: 1024 regular empty file
Device: 0,35 Inode: 139446 Links: 1
Access: (0700/-rwx------)
Access: 2024-06-17 14:42:16.000000000 -0400
Modify: 2024-06-17 14:42:16.000000000 -0400
Change: 2024-06-17 14:42:16.000000000 -0400
Birth: -
Viewed from the host:
Let me know if you still need any info.
I have a quick question. The "viewed from the host" screenshots of the file properties are residing on drive Y. Is this a network share from the host? Or is Y a local drive? You mentioned that the host drive is using the NTFS file system. I would like to know if there are more components involved.
Thanks. Steve
There isn't a NAS or other components. It's local to the host (Windows 10 Pro version 10.0.19045). It's a Seagate 2TB 7200 RPM 3.5 Internal Hard Drive (Model ST2000DM001) slotted into a SATA 3 interface on the motherboard of the Windows 10 PC. Just doubled checked to make sure it wasn't shared as well:
Is anyone looking into this? A few weeks ago I noticed shared folders on Debian 12 also manifests this behavior. Kinda difficult to use 'make' on source code in shared folders when the dates on files created with 'touch' are hosed.
Hello Rick, Sorry for not responding earlier. Thank you for the additional information.
There isn't a NAS or other components. It's local to the host (Windows 10 Pro version 10.0.19045). It's a Seagate 2TB 7200 RPM 3.5 Internal Hard Drive (Model ST2000DM001) slotted into a SATA 3 interface on the motherboard of the Windows 10 PC. Just doubled checked to make sure it wasn't shared as well:
Just for clarification, your Y drive has NTFS file system on it, is that correct?
I have filed a bug and assigned this to myself. Unfortunately, I am swamped with higher-priority issues right now. Once those are taken care of, we will schedule this issue to be addressed.
Thanks for your patience and understanding. Steve
@lousybrit thank you for the update. Its formatted in NTFS. Nothing complicated just an additional drive attached to Windows.