IO error with shared folders when moving files

XukHue commented 2 years ago

Describe the bug

Consistently get IO error when moving files from one shared folder to a different one. Copying works fine, moving from shared folder to/from guest or within a single shared folder works fine. Only moving one to another fails, and that always fails. This has been reproduced on multiple machines.

Both host and guest are Ubuntu 20.04, all the latest updates to all products involved. Moving has been attempted with Nautilus, Nemo and "mv", all fail with same Input/Output error.

There is a known problem that shared folders don't mount at boot. This error occurs using both of the workarounds to this problem that I'm aware of. Which is to say both the "add a line to fstab" and the fuse method documented here: https://kb.vmware.com/s/article/74650

Let me know if more information is need to reproduce this problem.

Reproduction steps

1 Create multiple shared folders 2 Attempt to move a file between them.

Expected behavior

File should have been moved. More specifically copied from one location to another and then deleted from the original location.

Additional context

No response

PaTHml commented 2 years ago

The usual is needed, "all latest updates to all product involved" means nothing really as it varies by distro and repos used. So lets be specific:

version of the VMware Workstation (need I say full version?)
version of open-vm-tools and open-vm-tools-desktop installed in the VM.

Ubuntu 20.04, is that meant as "vanilla" install or was apt update and apt upgrade run along the way? A simple uname -a would help make sure we can reproduce the setup.

Whats the window manager/desktop used (x11, gnoome, kde, ...)?

Any more details than "IO errors" on the issue?

PaTHml commented 2 years ago

We can compare notes:

Installed Ubuntu 20.04 and ran apt update / apt upgrade ; I end up with open-vm-tools 11.3.0 packages.
Got VMware Workstation pro 16.2.4 evaluation from the download site.

Let me know f that's inline with what you have

XukHue commented 2 years ago

uname -a Linux ubuntu 5.15.0-52-generic #58~20.04.1-Ubuntu SMP Thu Oct 13 13:09:46 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

All updates as in Ubuntu 20.04 plus sudo apt update sudo apt dist-upgrade

for both guest and host.

VM-workstation player latest distribution publicly available: 16.2.4 build-20089737 vm-open-tools and desktop is the latest in the Ubuntu repository, sudo apt list gives: open-vm-tools/focal-security,focal-updates 2:11.3.0-2ubuntu0~ubuntu20.04.3 amd64

Input output error is really all it's giving me: mv: cannot move 'testdoc.txt' to '/mnt/hgfs/hosthome/testdoc.txt': Input/output error

Since you are looking for more details does that mean you are having trouble reproducing this? The problem happens on several working machines but I haven't tried spinning up a fresh environment to reproduce it there.

PaTHml commented 2 years ago

I'm still getting a setup sorted out. I should be able to repro in a couple hours. The VMware workstation host (Ubuntu 20.04) setup:

I have 3 disks, /dev/sda is the main OS. then /dev/sdb and sdc are mounted as /hdd/2 and /hdd/3
I'm having these last 2 as shared folders (R+W), for the VM Ubuntu 20.04 guest OS. I have a couple manual steps to do to finish the prep and give it a go.

I'll Let you know if I can repro or not.

Something like this was reported in 2020, in issue #437 . I'm wondering if it is something similar. In their case though, the first file operation would fail; but the following operation (or repeating the original) would not see the input output error.

Like something got unloaded and took too long to reload for the operation to go through.

Could be unrelated.

Thanks for the info!

PaTHml commented 2 years ago

remind me to disable markup ...

PaTHml commented 2 years ago

At the time of the error, do you get any output from the command: modprobe -v fuse

PaTHml commented 2 years ago

reproduced

Filed an internal bug for it.

copy across shared folders works, move on the same share works move across shared folders fails as described.

cappallo commented 1 year ago

I had the problem described in #437 and like others, it was solved by adding max_write=32768. But I recently updated to Ubuntu LTS 22.04 and it seems like it uses fuse3 which no longer supports max_write option, so now this problem is back; I can't copy any files out to a share which are of any substantial size. Unsure whether that is the same as this, but figured I would mention it. Using open-vm-tools 11.3.5-1ubuntu4.1.

johnwvmw commented 1 year ago

@cappallo Responded in #437, Suggest dropping the "max_write=nnnnn" option from the /etc/fstab line since not needed, not used and unrecognized in fuse3.

PaTHml commented 1 year ago

Just making it clear: This issue is for failure to move folder file across different shared folder. The file transfer issue are handled elsewhere (see previous comments).

dbjungle commented 1 year ago

I just started to get this after upgrading to VMware Workstation 17. Also present on 17.0.1. My files are present, but if I do something like "touch filename" on the shared folder I get an error stating "touch: setting times of 'filename': Input/output error".

johnwvmw commented 1 year ago

@dbjungle Would you please provide the following so that we can try to reproduce the issue.

host OS and version:
guest OS and version:

Are you experiencing I/O errors with command line moves within the shared folders or only when updating file attributes with the "touch" command?

dbjungle commented 1 year ago

Host Windows 11 Pro 22H2 22621.1105 VMware Workstation 17.0.1

Guest Operating System: Manjaro Linux KDE Plasma Version: 5.26.5 KDE Frameworks Version: 5.102.0 Qt Version: 5.15.8 Kernel Version: 6.0.19-4-MANJARO (64-bit) Graphics Platform: X11 Processors: 12 × AMD Ryzen 7 5700G with Radeon Graphics Memory: 7.7 GiB of RAM Graphics Processor: SVGA3D; build: RELEASE; LLVM; Manufacturer: VMware, Inc. Product Name: VMware20,1 System Version: None

Moves appear to be fine, but creating a new file via touch is producing the error.

johnwvmw commented 1 year ago

This certainly sounds different than the original issue which is being track internally on an individual problem report.

Would you please open a new issue for this Workstation 17.x and shared folders "touch" issue, restate your individual problem(s) encountered and copy along the above configuration information. That will avoid multiple communication threads on a single issue and allow your issue to be tracked separately.

I will open an internal problem report as soon as you open a new issue.

Thank you.

vmware / open-vm-tools