I have an instance of virtualbox running Fedora 15 on my Windows XP machine. The Windows box (Z8GQ9439) is sharing a folder (rlevesq).

I am mounting that drive in the /etc/fstab as follows:

//Z8GQ9439/rlevesq  /mnt/rlevesq        cifs    uid=500,gid=500,rw,exec,file_mode=0755,dir_mode=0755,credentials=/home/rlevesq/.cifscred    0 0

I am able to mount the drive fine. I can write to it and read from it.

The problem is that eventually the mount will become inaccessible from linux. It seems to happen when I am doing I/O intensive stuff in Windows, such as compiling C++ code.

When that happens I can't run ls /mnt/rlevesq. Even sudo umount /mnt/rlevesq doesn't work. In fact, when I run those commands they lock up the shell in which they were run.

dmesg gives the following error

[63823.762680] CIFS VFS: Server Z8GQ9439 has not responded in 300 seconds. Reconnecting...
[64070.860398] CIFS VFS: Unexpected lookup error -512
[64101.643986] CIFS VFS: did not end path lookup where expected namelen is 0

At this point, it doesn't matter how long I wait, the folder remains inaccessible. The only solution I've found is to restart the virtualbox.

  1. Is there some way to recover from this without restarting the linux box?
  2. Can anything be done to prevent this from happening; any mount option I've missed?

We had a lot of trouble with a similar setup when we lost our primary domain controller. The cifs mount suddenly disappeared and we needed to reboot.

The solution was to create a local winxp user for the mount instead of using the domain user.

Note: We used vmware. We've moved away from cifs and now use the vmware tools and hgfs for sharing. If you can move away from cifs, do it. I see there is vbfs as an equivalent. Have you tried?

  • Mounting as a local user seems to have solved the locking up problem. Thanks. I am still seeing I/O errors but I think that is more CIFS being crappy than anything else. I was unable to use the vboxsf because it didn't work with svn. – curlingdude Sep 6 '11 at 14:56

I speculate this problem is caused by the default NAT network of the guest created in VirtualBox. With this NAT network, the host OS can't talk to the guest freely (can't ping, can't initiate a session), thus this issue.

My solution is to create a host-only network in the guest so that my guest OS has two networks: NAT for internet connection and host-only network for sharing files. It's easy, normally you just need to enable the network Adapter 2 of your guest OS and let it attach to the "Host-only Adapter." After rebooting your guest, you should be able to mount the host's shared directory as before, and the mount should be reliable. To verify that the host-only network really works, you can try to ping the guest from the host.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.