Samba does not work

[waqarz]

• A brief description

After installation, samba server fails to start/restart:

username@DESKTOP-123:~/test$

sudo service smbd restart
initctl: Unable to connect to Upstart: Failed to connect to socket /com/ubuntu/upstart: Connection refused
* Stopping SMB/CIFS daemon smbd [ OK ]
* Starting SMB/CIFS daemon smbd [fail]

I have one very simple share directory, and no shared directory appears on exploring after this fail.

• Expected results

a. Fail should not appear.
b. Directory sharing should start working.

• Actual results (with terminal output if applicable)

sudo service smbd restart
initctl: Unable to connect to Upstart: Failed to connect to socket /com/ubuntu/upstart: Connection refused
* Stopping SMB/CIFS daemon smbd [ OK ]
* Starting SMB/CIFS daemon smbd [fail]

• Your Windows build number

Version 1607 (OS Build 14393.10)

• Steps / commands required to reproduce the error

Fresh WSL install

sudo apt-get install samba
sudo smbpasswd -a username
mkdir test
sudo nano /etc/samba/smb.conf

Add in the end:

[share]
path = /home/username/test
valid users = username
read only = no

Then run the command:

sudo service smbd restart

• Strace of the failing command

log.txt

• Required packages and commands to install

samba

See our contributing instructions for assistance.

[rodrymbo]

That's probably because the service command requires upstart, which isn't working. So anything that uses upstart or service likely fails with the same message.

You could always look at /etc/init.d/smbd or the smbd docs (whatever they are called) to see if it is possible to launch the daemon manually, that is, without using the service command. (You could, for example, try to launch it in one window, then minimize that window.)

Otherwise what you are reporting is that no service works, and no program will continue running when you close the window or log out, which we already knew.

[waqarz]

@rodrymbo thanks for the comment, but where is the issue reported that says no service will start? The link you provided is a feature request to let services run after windows is closed, which is not what I have asked about.

[rodrymbo]

Yeah, I looked briefly for UserVoice entries about service or upstart, and finally just used the "continue running" entry, since that is a prerequisite for services anyway, and getting it running sort of implies getting all services and daemons working. But you'd be justified in starting your own UserVoice entry for upstart. ;-)

I'm pretty sure upstart expects to be started by init at boot time, and I haven't figured out a way to do that from bash in WSL manually, though I haven't tried very hard.

For reference, sshd doesn't start with the normal sudo service ssh start command (which I think uses upstart), but it does from sudo /etc/init.d/ssh start, which is just a bash script. Maybe samba can start the same way?

[fpqc]

Samba might also fail if it does not recognize the filesystem (which it won't, at least right now). Samba uses filesystem information to determine if unix permissions (or other linux-only features) can be assigned or not.

[therealkenc]

Blocking on #468 here. Guessing smbd will hit inotify soon after that. Anyway, once #468 is addressed, starting another CIFS server on the same IP and port as the one already running there is going to be somewhat problematic.

[dreyks]

/var/log/samba/log.smbd says ERROR: Could not determine network interfaces, you must use a interfaces config line. This may be caused by

$ ifconfig
Warning: cannot open /proc/net/dev (No such file or directory). Limited output.

Settings interfaces in smb.conf does not do a thing

[drrob1]

I just want to add that I cannot get samba to work either, on bash on windows10. I'm getting the same error.

Is there any work-around that has been developed since August 4?

[fpqc]

@drrob1 Not sure, but the latest build added more Inotify-related features. Try 14942?

[therealkenc]

There's inotify which is fixed, but it also needs #468, which is still in the works. I am assuming here that people understand there is already something somewhat important occupying localhost:139/445 on your Windows machine. You can pick a different port, but I have to wonder about the glaring absence of people mentioning that when they "try samba".

[GSam]

I've managed to get as far as smbd running, but it can't seem to bind to the port (despite using a seemingly unused one). As a start, I've just tried to get it to accept guest connections with the following smb.conf:

[global]
map to guest = bad user

[mapped]
path = /tmp/
guest ok = yes
readonly = false

Command: sudo bin/smbd -i --option='smb ports = 65500 65501' --option='interfaces = eth0' -s /tmp/smb.conf -d3

Last bit of log:
open_socket_in(): setsockopt: SO_REUSEPORT = true on port 65500 failed with error = Invalid argument
open_socket_in(): setsockopt: SO_REUSEPORT = true on port 65501 failed with error = Invalid argument
open_socket_in(): setsockopt: SO_REUSEPORT = true on port 65500 failed with error = Invalid argument
smbd_open_one_socket: open_socket_in: Address already in use
open_socket_in(): setsockopt: SO_REUSEPORT = true on port 65501 failed with error = Invalid argument
smbd_open_one_socket: open_socket_in: Address already in use
reloading printcap cache
cups_pcap_load_async: already waiting for a refresh event
reload status: error
waiting for connections <------ Neato

It seems that the Linux subsystem does not like 0600 permissions (on reopen possibly) and so I went through the code and set it to 0660 + deleted the old tdb files.

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

[GSam]

After disabling the ipv6 handling code I've managed to establish a local connection within bash. Still trying to determine if the share is visible outside of bash.

~/samba$ sudo bin/smbclient -L localhost -p 1234 --option='interfaces = lo'
sudo: unable to resolve host DESKTOP-C8HLOCF
WARNING: no network interfaces found
Enter root's password:
tdb(/usr/local/samba/var/lock/gencache_notrans.tdb): tdb_open_ex: tdb_new_database failed for /usr/local/samba/var/lock/gencache_notrans.tdb: Invalid argument
tdb(/usr/local/samba/var/lock/gencache_notrans.tdb): tdb_open_ex: tdb_new_database failed for /usr/local/samba/var/lock/gencache_notrans.tdb: Invalid argument
tdb(/usr/local/samba/var/lock/gencache_notrans.tdb): tdb_open_ex: tdb_new_database failed for /usr/local/samba/var/lock/gencache_notrans.tdb: Invalid argument
Domain=[WORKGROUP] OS=[Windows 6.1] Server=[Samba 4.6.0pre1-DEVELOPERBUILD]

    Sharename       Type      Comment
    ---------       ----      -------
    mapped          Disk
    IPC$            IPC       IPC Service (Samba 4.6.0pre1-DEVELOPERBUILD)

No idea what putting files on this share will do.

[GSam]

It seems to exist outside the bash terminal. Just transferred a file from my Samba server in bash to an Ubuntu VM in Virtualbox, no corruption or anything.

(Accessing shares on Windows natively seems to require 445, so some redirector is probably required)

[therealkenc]

I see Dokany 1.0 was released recently. There should be just enough pieces here to do something really silly with a little effort...

[fpqc]

@therealkenc So I'm not clear on this, but does dokany allow a relatively easy port of ext4 for Windows? Also, how does it handle Windows ACLs?

[therealkenc]

There's a read-only Ext4 FUSE implementation here. It was done for OSX but a Windows port should be possible in theory (anything is "possible"). Ext4 is a different animal than SMB/NFS though, as you are dealing with the block layer, say on a USB device. If one were to do that users/permissions aren't an issue because it's a real Ext4 filesystem. [Incidentally there is a USB over IP project.]

Anyway what I was referring to was that one should be able to do a SMBNetFS port to Windows with some effort. With SMB/NFS you just need a socket API, which Mingw-w64 is happy to provide. A CLI been done before. There's a userspace NFS server for Linux, although I don't think anyone has tried it on WSL yet. The open source NFS 4 client for Windows is a little stale but I assume could be resurrected. And then of course the is the native windows NFS client for Windows 10 Enterprise.

Which is to say, sooner or later someone is going to mount a WSL VolFs (/home) on Windows.

As for permissions, that's on Dokany's TODO list. Not that I suspect anyone probably cares a lot, as I mentioned in another thread. People have been mounting SMB/NFS shares as 'user whatever' for 25 years.

[krisbulman]

As of build 14965, I am showing Samba restarting OK

* Stopping SMB/CIFS daemon smbd [ OK ]
* Starting SMB/CIFS daemon smbd [ OK ]

I cannot seem to connect to the share, however. Tried the same commands as Gsam on eth0 and lo, got:

open_socket_in(): setsockopt: SO_REUSEPORT = true on port 1234 failed with error = Protocol not available
open_socket_in(): setsockopt: SO_REUSEPORT = true on port 1235 failed with error = Protocol not available

[fpqc]

@krisbulman Wondering, even if you could get Samba working, won't it have troubles with ACLs not being supported by the LXSS "interpretation" of the filesystem?

[GSam]

@krisbulman It looks like it still needs some code removed (for SO_REUSEPORT, or implemented on their side). I'll see if you can disable it without any code changes, but you'd probably still need to recompile regardless.

[therealkenc]

@GSam (or anyone) knows enough Windows networking-fu to do the port redirect I'd be grateful for pointers. I took a brief run at it a few weeks ago with TAP but it's not really my area and documentation on the interwebs seems light on the whole thing. I am sure some MCTS out there can do this in their sleep.

[acesnik]

There is a lot of detail here that I don't quite understand, but I'll just add that I'm having what sounds like a similar issue.

sudo mount -t cifs -o username=anthony //NetworkDrive/share /mnt/NetworkDrive works on my box running ubuntu after installing cifs-utils and making the folder in /mnt, but it doesn't work in Bash on Windows after a similar setup. No errors are returned.

[therealkenc]

The OP in this thread is about running a CIFS server on WSL, which "works" per @GSam (comment), but isn't especially useful at the moment because a CIFS server on WSL will collide with the CIFS server running on Windows unless you use a nonstandard port.

You just tried running a Samba client on WSL, which won't work right now because no FUSE. User Voice is here.

[waqarz]

I initially opened up this issue quite some time ago, now we have moved to Ubuntu 16.04 with added support for networking. Samba installs and starts now fine (compared to errors noted initially), but shares never appear and/or get mapped.

Given that its not possible to edit WSL files in Windows, Samba could have been one way to be able to edit the Linux files (other options as WinSCP do work but its not well integrated in Windows Explorer as Samba). What I would like to understand is:

• Is Samba currently officially not supported?
• Is it expected to be supported in future releases?

Thanks!

[therealkenc]

Samba has worked out of the box since ipv6 (#982) and inotify (#216) were added. There is no such thing as officially supported or unsupported in WSL.

The problem is not WSL or Samba, but that Windows hogs port 445 on all interfaces. To compound matters, there is no such thing as net use L: smb://localhost:3445/myshare. Which is just sad. So very very sad.

I have tried to redirect smb, but this SO post and this SF post are not encouraging. I went so far as to try using a loopback OpenVPN tunnel, but long story short, failed miserably. I am pretty sure it can be done one way or another with Windows Packet Filter, but having been defeated once already I haven't pursued it. I am sure a Windows networking guru would know how to make this work (looking at you, @JasonLinMS).

I have looked a little into doing it with dokany and libsmbclient (message), but that route does smack of "effort".

Anyway, in the mean time WebDAV might hold you over. Screencap 'cause why not. And you can vote for editing WSL files in Windows on User Voice here.

[waqarz]

Thanks @therealkenc for the detailed overview. I am now also trying to move/keep all my data in Windows filesystem as suggested by the MS post; symbolic links also seem to be fully functioning as well, so may be this solution addresses all my use cases.

[dreyks]

except all of the files are seen as executables which may not be desired

[therealkenc]

@waqarz - junctions, sorta; symbolic links, no. You'll still find yourself in a state of grief if you try to, for example, clone a git repo with symlinks in WSL and use them in Windows, and visa-versa. But I gather they are looking at it (#1475).

[rlabrecque]

Some improvements are coming: https://blogs.msdn.microsoft.com/wsl/2017/04/18/file-system-improvements-to-the-windows-subsystem-for-linux/

[fpqc]

Wow, neat!

[therealkenc]

The original request here was for smbd, which has been working for some time now since #982 #468 #216 and some other stuff was addressed. Let's call it Creators Update (15063) or thereabouts.

Mounting SMB/CIFS client shares (a different request) was addressed with the filesystem improvements noted a couple of posts back. Commandline smbclient works too, probably for ages. Mounting native Samba shares would require FUSE per User Voice.

Note that although smbd is operable, that doesn't make it especially useful for interop with Windows on localhost, which is what a lot of people really want here. But this is because the CIFS port is already spoken for by Windows, not because smbd is broken on WSL. But if you fire up smbd on a custom port on WSL, you could for example connect to it over the wire with a Samba client using native Linux. Connecting over localhost would require either (a) WSL supporting it's own network space like Docker and other VMs, or (b) Windows supporting connecting to CIFS shares on a non-default port (like WebDAV allows).

[WSLUser]

@therealkenc Could there not also be the possibility of forcing Windows to share the CIFS port with WSL instead of forcing Windows to recognize a non-default port? Some type of QoS/Load balancing that determines what needs the port more and ability to set certain apps within WSL to a higher priority than something in Windows that's not being utilized 100% of the time. Perhaps also another possibility is allowing ports such as CIFS and SSH to accept simultaneous use from both Windows and WSL? This would seem to me to be the better solution than using a non-default port that could potentially be compromised by anybody wanting to a run a port-scan against your computer/network and noticing an unusual port being open. Pen testers would have a field day with the non-default ports being utilized for services that don't belong there.

[therealkenc]

Could there not also be the possibility of forcing Windows to share the CIFS port with WSL instead of forcing Windows to recognize a non-default port?

The problem here is Windows CIFS hogs listening address 0.0.0.0. Even if you could convince the greater Windows group to "share", which let's just cut to the chase and concede isn't in the cards, you have no priority (differentiation) to hang your psudo-QoS hat on. WSL localhost is Windows localhost.

If you differentiate "WSL localhost" and "Win32 localhost", well, that's pretty much the definition an address namespace; in other words option (a). It isn't really a load balancing analogy. If I fire up smbclient on WSL targeting destination localhost, those packets need to be routed with specificity. I might want WSL Samba listening on 445. I might want Windows CIFS on 445. That isn't "sharing". That's routing.

But yes, in short, if WSL supported all the routing/filter goodness of Real Linux, we'd be golden.

This would seem to me to be the better solution than using a non-default port that could potentially be compromised by anybody wanting to a run a port-scan against your computer/network and noticing an unusual port being open.

No; whatever the port scanning attackers think they intend to do on port 3445 they can do on port 445. 127.0.0.1:3445 can't be compromised any easier or harder than Samba running in a VM on 192.168.0.123:445 on the same machine. Ditto goes for ssh on 2222 or apache2 on 8080.

[GSam]

@therealkenc There's actually a way to disable the Windows CIFS server. I don't know what the implications are, but it could be useful. The Samba team seem to have played around with it a little. It's probably of most use to you to figure out what to do with it. Do you have somewhere I can send it?

[therealkenc]

Yeah I almost mentioned forgoing Windows CIFS as a possible scenario, but we were already straying from actionable WSL territory with respect to the OP and I thought better to leave that implied. Link whatever you got here if you like; no harm in that (shrug). But folks will overall probably get better service from being involved with the Samba community, as with any other target platform.

[GSam]

https://github.com/GSam/samba-scripts/releases/download/temp/Free445.tgz