To be more specific, this is a Virtualbox Ubuntu virtual machine running on Windows 10, grabbing a file across SMB from a Samba file server running inside the Windows Subsystem for Linux through Bash.

(Why not show native Windows explorer? It's running on a non-standard port 1234, and haven't had the time to make a port redirector.)

EDIT 18/05/20: Samba should run without much hackery required now. Some ideas on how to do port redirection are here.

Who in their right mind would want this?

That's an interesting question. And the answer is possibly quite a few people, maybe even the guys at Microsoft. Long story short, this has a number of implications on the future of interoperability.

Details

What does Samba actually do?

There are a lot of misconceptions about what we, the Samba Team, do, including the view that we somehow have access to Windows internals which is simply not true. Despite saying we are a standalone file server, a lot of the real effort we put in goes into working out the kinks between Linux-Windows or vice versa. The differences, we make sure they're well-known and critically, we strategize ways to resolve them.

Why am I doing such a bizarre thing?

In reality, this story goes back a bit further than that. I am a member of the Samba Team who works on the open source Samba project. Every year the team gets invited by Microsoft to an interoperability lab at their Redmond campus to do some testing and talk over interoperability issues. Last month, this all went down and being a fairly new member this was the first time I attended. Realizing that I probably needed to take a laptop to do Samba dev work, and hearing about this new-fangled "Bash on Windows/Ubuntu on Windows/Ubuntu NT/WSL/Interix 2.0/Cygwin but not Cygwin" I wondered if I could actually use Windows as my dev environment. Challenge accepted.

The results were somewhat surprising. I could compile, build and install Samba. It didn't seem like I could run it (standalone smbd or AD), but with a few hacks, a number of the client tools just worked. I could do git, ssh and manipulate cloud Ubuntu instances which could run Samba. And at the end of the day, I could do a surprising amount of development, with a significant portion of the code patching and code searching directly on my laptop.

What perplexed me the most was that, believe it or not, there were actually some things I could do on this bizarre system that I could not do at work on vanilla Ubuntu.

The Microsoft interoperability/protocols team are actually pretty cool guys. It's their job to worry about the wider ecosystem (that's not necessarily Windows), and it's their job to push (maybe nudge) the company in the right direction when it comes to guys like us. I managed to show off Bash on Windows to a few Windows engineers who were quite surprised at what it could do. We also spent some time spent conjecturing what we could do with this subsystem and what it could mean for Windows (and basically everyone else), but this group of people were still a very separate team. The end of the trip came and I didn't get to meet any of the Bash on Windows guys I'd hoped to have maybe caught up with while I was in Seattle. Shake their hands and talk about the kind of stuff they were working on.

Why is any of this important?

The only thing that I've managed to test so far is that guest access to Samba shares are accessible and that a file can be extracted from them. Other functionality is likely buggy, but on the other hand, if it got this far with the existing implemented syscalls then it can probably get a heck of a lot further without any further change on their side (and who knows with new fixes rolling in all the time). None of that is the point though. The fact that Samba can run on Windows at all, thanks to almost entirely the work of Microsoft engineers is frankly nuts. And it's not just our software, it's everyone else's.

I'm too young to understand the true depths of the bad blood between Microsoft and the free/open source software community. In some ways that might be a good thing. But the ways I hear my colleagues speak, this is really a very different world to the one they understood (so much so that the odd brain explodes when Microsoft open sources yet another thing). I guess in part this is because of guys like me, on their side too. For the protocol teams, thanks to legal action, none of this is so strange. But for the rest of the company to be beginning to realizing that our ecosystems actually co-exist (intentionally, through a forced hand or otherwise) is incredible. The protocol teams, like the rest of the company are slowly moving to open source and they want our advice, they want to know how it works, how we collaborate, how licensing works, how GPG works for instance and they're asking for tips on what managing a community is like.

Furthermore, when you start removing the GUI, stripping the rest of Windows down (like they are with Nano servers), what the heck are you even running anymore?

Crazy ideas

If I can get the file server running, then Samba Active Directory should not be that far away. The file server is not actually my area, so getting that working still blows my mind. Active Directory would've seemed even more of a pipe dream than just the file server.

Maybe if we can get replication going between SMB shares (DFSR? If we ever manage to implement it...) we could have a genuinely consistent view between Linux and Windows on the same machine or otherwise.

This could all open us to a whole new range of network topologies, business solutions. The possibilities are endless.

Some technical thoughts

How do Samba (SMB) shares compare to the driveFS functionality provided by Windows? Is this like an inverted driveFS?

If anyone else is crazy enough to want to make (see: Hack) their projects to run on Windows, there's a few things I noticed:

The Bash on Windows Github page for issues is useful in determing what features might be missing that you need.



You probably need to know the code and how to wield a debugger. I noticed one issue with 0600 permission (WHY?) when creating Samba tdb databases. Looping through the debugger it managed to create them with 0660 with no problems, so I went through the code and modified the open flags.



Strace is your friend. There was a port binding issue that I resolved by analysing how Samba opened ports and how a python script did so (successfully). In this case it was an issue with ipv6 where binding :: collided with 0.0.0.0 or something more subtle and buggy on the Windows end. All I did was remove the ipv6 handling altogether in the bind.

There are some current issues I forsee for actually trying to integrate this in a meangingful way into Windows. In my example, I had to bind to port 1234 instead of the standard SMB ports because the Windows file server was running. I suppose we could disable that, but I don't know what relies on it (in Bash for instance). Another such problem is that mounting shares is restricted to port 445 I believe. There could possibly be a redirection container to expose the port on 445, or even simpler still, a new interface. But I'm not sure if that any newly created interfaces won't simply be bound in the same way. I think I need really more input from someone else.

I haven't quite figured how much I've disabled to get all this running (or their implications), but any work should eventually get here:



https://github.com/GSam/samba/tree/bash

Contact