12

I am trying to connect/mount a point on my Ubuntu 16.04 LTS VM to a share on the host which is a Windows 10 with no success. The goal is so that I can download files on Ubuntu(VM) and transfer them to the Windows host. The Windows share is accessible from other windows hosts on the same network but not from the Ubuntu VM, even though there is network connectivity as I can ping(VM configured in "Bridged" mode). I have tried running:

sudo mount -t cifs -o username=username //ip_address/Windows_Share /mount/point/Ubuntu

This comes back with an error indication that the host is down, which is not true since the share running on it can be accessed by other Windows boxes. I have read some posts about it and someone mentioned there is a conflict with the SMB version used by Ubuntu and Windows 10, which now disables SMB1. So they advised to run the below to check:

smbclient -L <windows_ip> -U <windows_user> -d 256

And indeed I have got an error:

protocol negotiation failed: NT_STATUS_CONNECTION_RESET

Then I run:

smbclient -L <windows_ip> -U <windows_user> -m SMB2

And yet another error:

NetBIOS over TCP disabled -- no workgroup available

Can anyone suggest a fix/advise how I can mount the Windows share on Ubuntu?

dude
  • 311
  • 1
  • 2
  • 6

2 Answers2

14

Sounds like you are on the right track. If the problem is related to SMB1 the following will resolve your issue.

First make a copy of smb.conf

cp /etc/samba/smb.conf /etc/samba/smb.conf.orig

After making the copy

sudo gedit /etc/samba/smb.conf

Feel free to use vi/vim/nano if you do not prefer gedit

In the file, add the following in the [global] section

client min protocol = SMB2
client max protocol = SMB3

After saving the edits to the file. Restart SMB

sudo service smbd restart

If this does not work please include errors.

xguru
  • 141
  • 2
  • I have tried the configuration you've suggested and ran the below after restarting smbd and even did a full system reboot(just to make sure): smbclient -L -U -d SMB2 But still nothing: > Connection to failed (Error > NT_STATUS_RESOURCE_NAME_NOT_FOUND) NetBIOS over TCP disabled -- no > workgroup available The battle continues... :) – dude Dec 02 '17 at 18:18
  • I don't seem to have a smbd here in debian stretch server: `sudo service smbd restart` => `Failed to restart smbd.service: Unit smbd.service not found.` :-( Changing smb.conf didn't help but add `-o vers=3.0,` from the other other answer did. – Peter V. Mørch Dec 04 '19 at 23:00
9

Ok, sorry for coming back so late to this. The fix basically is this:

sudo mount -o vers=3.0,username=<your_username>,uid=<your_user_id>,gid=<your_group_id>,forceuid,forcegid, //<ip_address>/<path_to_share> /<mount>/<point>/<local_system>

Note that I have skipped the "-t(--type)" option this time, since if this option is not specified "mount" will try and guess what system to use, and with all honesty, given the amount of reading I had already done on what was going on with Windows 10 sharing protocols, I chose to let "mount" do its magic for me. ;-)

Here for an extract of the "mount man page":

"If no -t option is given, or if the auto type is specified, mount will try to guess the desired type. Mount uses the blkid library for guessing the filesystem type; if that does not turn up anything that looks familiar, mount will try to read the file /etc/filesystems, or, if that does not exist, /proc/filesystems. All of the filesys‐tem types listed there will be tried, except for those that are labeled "nodev" (e.g., devpts, proc and nfs). If /etc/filesystems ends in a line with a single *, mount will read /proc/filesystems afterwards. While trying, all filesystem types will be mounted with the mount option silent."

Also, since "mount" could only be run as root, but other programs writing to this mount point aren't run as root, you will need to specify the user and group which you want to grant writing privileges(ownership) to the mount location, hence the use of: uid=<your_user_id>,gid=<your_group_id>,forceuid,forcegid,.

Done! @xguru, Thanks for the help!:)

dude
  • 311
  • 1
  • 2
  • 6
  • I am facing the same issue while trying to mount a share of a W10 box from my Ubuntu server. On all other W10 boxes, I do no need to specify the `vers=3.0` option. Why on this one ? Any idea on what causes the problem on the Windows side ? – M-Jack May 30 '18 at 15:38
  • @dude Thanks for this one and upvoted. For me, the `-o vers=3.0` was the crucial point (I never had tampered with `-t`). I came across it when I noticed that backups from Linux machines to a new Windows 2019 server were not working although they had worked fine to the old (W2K8 R2) server. – Binarus Jan 01 '20 at 23:46
  • 1
    @M-Jack : you probably solved it by now, but in case it's useful to someone, there is a more detailed explanation about these SMB protocol mismatches here: https://askubuntu.com/a/1070656/8822 – mivk Mar 09 '20 at 15:52