Opened 8 years ago
Closed 7 years ago
#15662 closed defect (fixed)
Shared Folders freeze under pressure
Reported by: | PierreYager | Owned by: | |
---|---|---|---|
Component: | shared folders | Version: | VirtualBox 5.1.2 |
Keywords: | freeze | Cc: | |
Guest type: | Windows | Host type: | Windows |
Description
I have a Windows 7 development box for my main project. I use shared folders to build the release executable (Delphi code, Git, Finalbuilder to create the installation package).
When I start the build under VBox 5.1.2, at a point in time, something freeze. The shared folders seems "disconnected" (visible from the windows explorer but not browseable anymore). And I can't shutdown the guest OS. Have to kill it from VirtualBox Manager GUI (or by clicking the "close" button)
Host is Windows 10 1607 v14388.0 Guest is Windows 7 Pro (updates applied)
With VirtualBox 5.0.26 (and below) it works. With VirtualBox 5.1.2 it fails even with Guest Additions 5.0.26.
Attachments (1)
Change History (39)
by , 8 years ago
Attachment: | Windows 7 Pro-2016-07-22-10-45-32.log added |
---|
comment:1 by , 8 years ago
I have the same issue, but with host Ubuntu 16.04. Whole OS gets stuck after accessing shared folders. Windows 7 and Windows server 2012 guests are affected, but Windows XP seems to work fine.
The issue began after upgrading from 5.0.24 to 5.1.0. Upgrading from 5.1.0 to 5.1.2 didn't do any difference.
comment:2 by , 8 years ago
I'm having the same issue. Host is Windows 7 x64, guest is Windows 7 x64. I've seen this issue with VB 5.1.0 and 5.1.2. Downgraded to 5.0.26 & it was fine. In my case, the guest is issuing lots of file reads & directory scans of shared files files/folders (no writes).
comment:3 by , 8 years ago
More details about my issue: Shared folders works fine on 32bit guests (Win7, WinXP). Freezing problems appears only with 64bit guests (Win7, Windows server 2012)
comment:4 by , 8 years ago
I have the same issue with 5.1.0 and 5.1.2. The last working release is 5.0.26.
It only happens when shared folder is used e.g. copying files from/to it. But then after some time it happens 100% times.
I run Win 7 Pro 64-bits guest on OS X host (10.11.6).
comment:5 by , 8 years ago
I have the same issue with 5.1.2.
I run a Win 10 64-bit guest on an arch linux host.
comment:6 by , 8 years ago
I have exactly the same problem:
Host ist ubuntu_12. The "freezing shared files" only happens on Win7_64 guest, Win7_32 and WinXP_32 guests work fine. Will downgrade to VB 5.0.28. Have not yet checked the behaviour of ubuntu_16 64 bit guest.
comment:7 by , 8 years ago
Same problem here on VBox 5.1.2, host: debian testing x64, guest: win8.1 pro x64. VBox release 5.0.24 works
comment:9 by , 8 years ago
follow-up: 11 comment:10 by , 8 years ago
I've reproduced this hang twice. But it takes quite a long tome to reproduce. Now the VM runs over weekend, zipping files on shared folder without a hang.
Could anyone please test if the problem is reproducible when using Guest Additions 5.0.x with VirtualBox 5.1.4 host? Thanks.
comment:11 by , 8 years ago
Replying to sunlover:
Could anyone please test if the problem is reproducible when using Guest Additions 5.0.x with VirtualBox 5.1.4 host? Thanks.
Still reproducible with Arch Linux (kernel 4.7.1) and VirtualBox 5.1.4 with Guest Additions 5.0.24r108355.
Compiling files which sit in a shared folder freezes the folder in just a couple of seconds for me (object files were also written to the shared folder).
comment:12 by , 8 years ago
Same here with Win10 (host) & Win7 (guest). If happening, it's usually not possible to shutdown the guest cleanly. Downgrading to VirtualBox 5.0.26 solved this quite annoying issue.
Seems that not pressure causes the problem, but moving focus from the guest to another application during IO on the shared folder.
comment:13 by , 8 years ago
Does anybody know if this issue is on VBox developers radar? So far I have not seen any comment from them.
comment:15 by , 8 years ago
I can corroborate this problem on a 64-bit Gentoo host with a 64-bit Windows 7 Guest OS. 5.0.24 and below is OK. Beyond 5.0.24 exhibits problem with heavy shared folder access.
comment:16 by , 8 years ago
I have the same issue. I tried to delete folder with 9000+ files, all shared folders became inaccessible, I was not even able to shutdown the OS, I needed to force shutdown from the host. The issue is perfectly reproducible in my setup. Guest OS: Windows 7 CZ (latest updates till the date); Host OS: Ubuntu 12.04.5 LTS; Virtual Box version: 5.1.4
comment:17 by , 8 years ago
Same here Windows 10 64 bit as host and windows 7 64 bit as guest. When fast downloading torrents it freezes. Thanks got I found this issue and downgraded to 5.0.26
comment:20 by , 8 years ago
Same here 5.1.4. Happy to see i'm not alone :)...it's very frustating all the RESET i have to do in the middle of the work.
comment:21 by , 8 years ago
priority: | major → critical |
---|
comment:23 by , 8 years ago
Same here with Gentoo host and Windows 8.1 64-bit guest. My use case is running uTorrent and seeding a lot of files from a share folder. 5.0.26 host is also fine here, even with 5.1.4 guest additions.
follow-up: 26 comment:25 by , 8 years ago
The hang is fixed in latest VirtualBox 5.1 guest additions (5.1.x revision 110849+) from https://www.virtualbox.org/wiki/Testbuilds
The bug was in the guest additions. VirtualBox 5.1 increased probability of triggering the bug.
Please test. Thanks.
comment:28 by , 8 years ago
If the fix is simple any chance to get a 4.2.37 guest additions build? For Vista and 7 guest additions after 4.3.13-93752 are just sluggish when enabling 3D. 4.2.36 work very well there if you only want to enable Aero and do some light work.
I practically hung my 7 VM with heavy load using the new additions.
comment:29 by , 8 years ago
frg, here is 4.2 additions build with the fix: https://www.virtualbox.org/download/testcase/VBoxGuestAdditions_4.2.39-110925.iso
comment:30 by , 8 years ago
Great. Big thanks. Much appreciated.
As a side note: I cleaned out all older files in the guest and reinstalled 110849. The 110849 additions are now behaving much better. I think I might be able to switch to the current line in the near future.
comment:31 by , 8 years ago
Win 7 Pro 64-bits guest on macOS host seems to work now without any issues with shared folders.
I have tested with the latest Vbox (5.1.7-110927) and additions (5.1.7-110861) testbuilds.
Thx!
comment:32 by , 8 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Fix is part of VBox 5.1.8. Please make sure to upgrade the Guest Additions.
comment:33 by , 8 years ago
I am seeing some similar behavior in VirtualBox 5.1.8 r111374. Guest Ubuntu 16.04, Host macOS Sierra 10.12.1, current Guest Additions installed. I'm using Eclipse to build sources (about 100 files) in a shared folder; it is about 3x slower than building on the command line (I assume Eclipse is indexing or whatever in the background during the build), and frequently something gets stuck in Eclipse (one core at 100% with a "Java" process) so it can't be closed correctly.
At that point, killing the Java process, or even shutting down the whole Linux guest doesn't work; it just blocks forever.
Interestingly, the VM doesn't report the CPU usage, and even after pausing the VM the VirtualBox process in the host still keeps using 100% of one core.
At that point, one can save the VM, close VirtualBox and reopen it, and the VM works.
So it looks like the sharing folder mechanism is getting stuck in the host-side part of VirtualBox.
comment:36 by , 7 years ago
Is there an update to this issue? I'm having the exact same problem, the shared folder suddenly freezes and there's no other way to make it work but to kill the vm (shut down won't work).
Host: macOS Sierra 10.12.5 Guest: Windows 7 Professiona SP 1, 64 Bits VirtualBox: 5.1.22 r115126 (Qt5.6.2)
comment:37 by , 7 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
This issue continues to happen to me, even after upgrading to 5.1.24 r117012 (Qt5.6.2)
comment:38 by , 7 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
DanielB, the originally reported problem has been fixed. There is no need to re-open the old ticket even if you experience a similar issue.
Open a new ticket, attach VBox.log of the frozen VM session and provide at least some info about the issue (when it happens, etc), if you want someone to look at it.
Guest OS log