The need for windows sharing..
A few days ago, I wanted to do a Oracle 12i installation on a x86 linux distribution using virtualbox. The media was available on an external hard disk, but I thought that instead of copying the 30+ G of media on unix virtual machine, why not just make it shared between the windows host OS and unix guest OS.
The quest for sharing..
And so began my quest for sharing files between windows and virtualbox unix OS (SuSE linux). I discovered that for sharing folders using virtualbox, the guest OS additions have to be installed.
I have seen that upgrading the kernel breaks the guest OS additions at times. After upgrading the guest OS from SuSE linux 9 to SuSE linux 9.3, the guest additions stopped working. The same problem also exists with vmware tools.
So first, I created a shared folder in the virtual machine’s definition:
After starting the Guest OS (Ubuntu),
root@gverma-laptop:/home/gverma# mkdir /mnt/winshare root@gverma-laptop:/home/gverma# mount -t vboxsf public /mnt/winshare
Mind you, the filesystem type is NOT vboxfs, it is vboxsf (s and f are interchanged). If you do not take note of this, you might end up wasting your time for nothing.
Now, we can check that the shared folder did indeed mount:
root@gverma-laptop:/home/gverma# mount | grep vbox public on /mnt/winshare type vboxsf (rw) root@gverma-laptop:/home/gverma# ls /mnt/winshare CyberLink desktop.ini Downloads Music Recorded TV Videos Desktop Documents Favorites Pictures StarzEntertainment Vongo
Let it be mentioned here that the vboxadd and vboxvfs (note that it has vfs after vbox) modules needed to be loaded for this to work:
root@gverma-laptop:/home/gverma# lsmod | grep vb vboxvfs 42432 1 vboxadd 24872 9 vboxvfs
The Caveat..
But, as every cloud has a silver lining, there was a caveat here for my problem.
The above case was just a demonstration of how the shared folder could have worked fine. I actually then went on to mount some linux media for Oracle Applications 12i for x86 intel platform. After the directory mounted all right, I had a really hard time adding the execute permissions to the rapidwiz files. Even after doing persistent # chmod -R +x commands, the shell scripts under the media were not showing the “x” execute flag.
This was very frustrating. It was probably just another virtualbox bug.
So, then I started looking around for more options. I had heard that many people had used samba with success and hence I started scouring the internet (Google Zindabaad! – Long live, Google!). Came across a link that explained how to do it in a succinct manner.
The good thing about sharing files from windows to unix using samba file system (smbfs) was that was that I did not need to run samba on unix at all.
Doing it using samba filesystem..
So here are some quick and easy steps for sharing a windows share using smbfs:
First things first. You need to create a network share for the folder that you want to share. In my case, I wanted to share an external hard disk that had the media for Oracle Applications 12i. So, I did a network share of windows folder (e.g. \\GAURAV-PC\media)
On the guest OS (Ubuntu), did the following:
# mkdir -p /mnt/media # smbmount //GAURAV-PC/media /mnt/media -o username=gaurav,password=welcome
Please note that // (forward slashes) worked for me. Some guides on the internet say that you need to use \\ (back slashes)
Note here that GAURAV-PC hostname was defined in the local hosts file to a resolvable IP address in the LAN. The Ubuntu Virtual machine was connected to the windows Host through a host only networking type interface, that allowed the host and guest OS to talk to each other.
# more /etc/hosts GAURAV-PC 192.168.0.2
Please note here that a ping to GAURAV-PC HAS TO work when you give the smbmount command. I wasted many hours trying to run strace on this command, just because it was hanging. The issue was that due to some strange happenstance, the ping to GAURAV-PC (windows host) was hanging.
The workaround was to ping the Ubuntu virtual machine (say 192.168.0.7) first from the host OS (windows), after which the ping to GAURAV-PC 192.168.0.2 started working from Ubuntu Guest OS. Strange, strange, I agree, but I am just a guy looking for solutions! I have seen this behaviour in Windows Vista home premium edition – host OS.
Make sure the smbfs module is loaded in the guest OS. If not, then load it using # modprobe smbfs:
root@gverma-laptop:/mnt/media/oracle_12.0.4/startCD/Disk1/rapidwiz# lsmod | grep smbfs smbfs 66296 0
Note that the Samba server does not need to run:
root@gverma-laptop:/mnt/media/oracle_12.0.4/startCD/Disk1/rapidwiz# ps -ef | grep smb root 6116 5616 0 00:00:00 grep smb
This was my samba configuration file:
root@gverma-laptop:/mnt/media/oracle_12.0.4/startCD/Disk1/rapidwiz# more /usr/share/samba/smb.conf [global] workgroup = WORKGROUP security = share usershare path = /var/lib/samba/usershare usershare max shares = 100 usershare allow guests = yes usershare owner only = yes wins support = no netbios name = GAURAV-PC
I am not exactly sure if setting the netbios name parameter was a major factor in making it work or not, but I guess it certainly did not hurt.
Now when I run mount command, the windows network share was showing up there just fine:
root@gverma-laptop:/mnt/media/oracle_12.0.4/startCD/Disk1/rapidwiz# mount
/dev/sda1 on / type ext3 (rw,relatime,errors=remount-ro)
proc on /proc type proc (rw,noexec,nosuid,nodev)
/sys on /sys type sysfs (rw,noexec,nosuid,nodev)
varrun on /var/run type tmpfs (rw,noexec,nosuid,nodev,mode=0755)
varlock on /var/lock type tmpfs (rw,noexec,nosuid,nodev,mode=1777)
udev on /dev type tmpfs (rw,mode=0755)
devshm on /dev/shm type tmpfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
lrm on /lib/modules/2.6.24-16-generic/volatile type tmpfs (rw)
securityfs on /sys/kernel/security type securityfs (rw)
rpc_pipefs on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
nfsd on /proc/fs/nfsd type nfsd (rw)
gvfs-fuse-daemon on /home/gverma/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=gverma)
//GAURAV-PC/media on /mnt/media type cifs (rw,mand)
Thankfully, I was able to make the unix shell scripts executable after doing this and launch the rapid wizard for 12i installation. That’s all I wanted.
Conclusion
Well, so there you have it. If you are using windows host OS and you upgraded your guest OS kernel, the guest additions may not work due to compilation errors. In such a case, you are better off using the samba file system as its much easier to deal with and not too much of a pain to setup.
Filed under: Virtualbox, external hard disk, file sharing, host only networking, samba, windows host | Tagged: cifs, host only networking, mount, samba file system, sharing files from windows to linux, smbfs, smbmount, unix, Virtualbox, windows network share, windows vista host

Excellent solution Gaurav. I wasted several hours with the same scenario.
You have some great articles here but I think this one may be a little misleading. I am no Samba expert but I have spent more hours than I would care to admit tweaking Samba to try to get it to do what I want. (I’m getting there but there are still a few nagging problems). Looking at what you’ve posted here there are a couple points which I think merit comment.
First, since you aren’t running the samba server, I doubt that your samba configuration file is doing anything. You could test this by getting your share mounted and working with it in place and then renaming it to something else, reboot, and do the same things you did before. If it is, in fact, being read, the netbios name parameter appears to be wrong. This would normally be the name of the samba server (i.e. the name of the machine the smb.conf file is on) and therefore would be the name the samba server (which you are not running) would broadcast via netbios to the rest of the workgroup and would respond to when a client on another machine attempted to access samba shares on the server. Since you are not running the server nor sharing anything with the rest of the network, using the same name your Windows machine would already be using via netbios is probably not an issue. It probably will be if you ever start the server, however.
The whole “usershare” feature which your configuration file is configuring is about individual users (as opposed to root) being able to dynamically share folders with other machines on the network, and requires the server to be running to work. It doesn’t have anything to do with accessing shares on other machines so, again, I suspect that the smb.conf file is not playing any role in getting your mount to work.
All in all, these are minor and inconsequential in your scenario but I thought it worth saying something since someone might look at your article and try to apply the principles to another scenario where they might not be so lucky.
One more thing, a bit of speculation as to the reasons for your needing to ping the machine to get the reverse-ping (and sharing) working, I think one possibility is that it is due to you not running the server. Since the Samba server uses the same protocols as Windows to try and look like just another Windows machine on the network, smbfs may be relying on the server to negotiate the link. That seems unlikely, though, since I suspect that smbfs was meant to stand alone without the server. Another possibility is that it is due to the fact that smbfs has been deprecated in favor of the cifs protocol which is apparently, much the same thing but is the result of Microsoft expanding its smb protocol somewhat to work beyond Windows (so that it could be used over the web). Since Vista is, so far, the latest release of Windows, its possible that it doesn’t work as well with smbfs, the older protocol. Finally, it may just be due to Windows’ firewall — it may have ignored your unsolicited pings but accepted them once Windows had initiated a connection with the machine.
Thanks for all the great articles.
- Les