Glad you got it working how you want! :)

I don't know enough about VBox shared folders to be of any reeal help to you, but perhaps there is some conflict between VBox shared folders and Samba? Perhaps check Samba error logs and see if there is anything of interest there. I'm not sure exactly what it'd be called but I would imagine you will find it in /var/log (that's where all log files should be).

Another attack you could try is to set up a Samba share somewhere else (that works - like you said you've been able to) and put a symlink to the VBox share in that. Not sure if it'd work but could be an easy hack if it does.

The other options are to install Samba on the host system and share direct from that (or you could try sharing that through your fileserver appliance). Or as your other host system is Linux too, you could try using NFS (Linux native network filesharing) and mount the NFS share in your fileserver and re-share that using Samba. Although TBH, re-sharing folders from your fileserver appliance may not work either if the current problem is a limitation of Samba (ie you may hit the same wall?)

Great you got that working and thanks for posting back.

As for your sharing requirements, I'm not sure if it's the best way, but the way I set up my shares is use Samba permissions to allow read access to shares (but set them to read/write for all that you want read access) and then use Linux file permissions to control write access. Assuming that the Samba and Linux user databases are correctly synced this works really well for me - only users/groups with Samba permissions can see the shares and only users with Linux permissions can write to them.

AFAIK the vmdk build already includes the basic VMware 'guest tools'. I don't think that it includes the VBox 'guest tools' though.

I remember reading somewhere that at least part of the rationale was that the VBox tools were much easier to install, and that they were also less useful (don't recall exactly, but think that it had something to do with the way the virtualisation was implemented, VMware guests are less functional without the 'tools'?) It may also have something to do with licencing? I know that the VBox tools aren't open source (although TBH I'd be surprised if the VMware tools were).

Either way, personally I don't see the point in using them (the 'guest tools') with a server OS (no GUI - so no need for the graphics bit), especially when the Fileserver appliance is already set up with Samba/Win filesharing which can be accessed/mounted/mapped from any host OS. And if you use Linux or OSX then you can use SFTP from the file manager instead if you desire.

Having VBox tools pre-installed may be your preference (and perhaps ideal for your scenario), but using a shared folder from your Windows host may be easier than installing VBox tools? Samba uses SMB/CIFS which is Windows native filesharing. Obviously TKL Fileserver works as a fileserver (it's intended use) but it can also work as a client (ie connect to Windows shares) - so no additional software required to install on either TKL Fileserver or the Win host.

While this won't work OOTB for some TKL appliances (as most of them don't have Samba preinstalled) it works fine for the Fileserver appliance. Even for the other appliances, if you only want to connect to a remote Win share (rather than create SMB/CIFS shares in Linux) this is easily configured. I have just created a wiki page on how to do this (I was going to post here but figured a wiki page may be better).

So you could easily create a script to configure this automatically for any new TKL appliances you install. Here is an example script (adjust the variables to suit your setup) that you could copy/paste in. Another alternative is to save the script on your host and copy it across (eg with SFTP via Filezilla or similar).

Create the file:

nano automountcifs.sh

the script:

#!/bin/bash -ex
# script to configure TKL appliance to connect to a remote Windows share

# set variables - adjust the value on the right to suit your system
winserver=WinPC
winshare=share
winuser=Win-user
pass=pass
workgroup=WORKGROUP
localfolder=/media/win-share

# install smbfs - uncomment if using on TKL appliance other than Fileserver
#apt-get update && apt-get install smbfs -y

mkdir $localfolder
echo "//$winserver/$winshare $localfolder cifs username=$winuser,password=$pass,workgroup=$workgroup 0 0" >> /etc/fstab

make it executable:

chmod +x automountcifs.sh

and run it:

./automountcifs.sh

As fstab is readable by anyone your password will be readable by all. There are a number of ways to get around that if you desire, but i wanted to keep it simple.

FWIW VMware server is free (but not open source) last time I used it, although I never used the host shared folders but AFAIK it should work OOTB (as I said VMware tools should be installed and ready to go on TKL VM appliances).

What do you mean doesn't need separate hardware? You can connect to a Win share from a TKL Fileserver VM OOTB, just need to mount it (plus make the mount point if it doesn't already exist). As long as there is a LAN/ethernet (virtual or otherwise) connection to the machine with the Windows folder you want access to it will work fine.

Seeing as you still need to edit fstab to make the shares auto-mount and new shares need to be added to fstab too, where is the advantage in using VBox shared folders over CIFS? Perhaps I'm missing something but just seems like an extra step (ie installing/configuring VBox tools) to acheive the same ends to me. I guess that's why you requested inclusion of VBox tools? But still if the same ends can be acheived OOTB as is... Is there some other benefit in using VBox shares/tools that I'm overlooking?

FWIW if you mount a Windows share with cifs and want to have full read/write as a user other than root then you also need to supply a UID and/or GID like is in your VBox fstab line (probably the same ones you used would work fine).

I think it's a worthy debate to have here on the forum but you are right in the sense that we probably shouldn't hijack this thread any further. So I have started a fresh thread over here. I put a link back here but also (very) briefly summarised the debate so far. Please feel free to elaborate if you'd like but I think I got it in a nutshell pretty much.

I also am about to obfiscate your email a littlte too so you don't get spammed too much. Hope you don't mind - if you'd rather it be an obvious email link please accept my apology and change it back and I will leave it be.