Failing to set up SMB/Samba

Almin · April 30, 2020, 12:42pm

Hey guys,

Short version: I’m inable to get acess to smb shares from a PC in my lan, localhost on the Turris seems to work.

Long version:
I have a Turris Omnia with the NAS perk. It’s set up and works fine with Turris OS 4.0.5.
I’m using the equipment from the NAS perk (casing, cables & other equipment) and two SSDs.

I’ve followed the instructions to set up the NAS from here:
https://wiki.turris.cz/doc/en/howto/nas

The btrfs-raid0 of the 2 SSDs seems to work fine.
lsblk gives (among others):

NAME         MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda            8:0    0  3.7T  0 disk /srv
sdb            8:16   0  3.7T  0 disk

In /srv I have a directory /srv/nas that I want to use as the smb shared directory.

If I ssh into the turris with my user account and “smbclient -L localhost” I receive:

Sharename       Type      Comment
---------       ----      -------
IPC$            IPC       IPC Service (OpenWrt)
NAS             Disk      

Server               Comment
---------            -------

Workgroup            Master
---------            -------

If I do it as root I instead get
tree connect failed: NT code 0xc0000022

So it seems the share is working locally, but here’s the catch:

If I try to access it using the IP of my turris (either from the turris itself using ssh or from another PC in my lan), with smbclient -L 192.168.3.2 I instead receive error messages, first from the turris:
Connection to 192.168.3.2 failed (Error NT code 0xc0000236)

And from my regular client PC:
do_connect: Connection to 192.168.3.2 failed (Error NT_STATUS_CONNECTION_REFUSED)

If I try to look up whether the port 139 is opened (sudo nmap -p 139 -sT "192.168.3.2") I get:

Starting Nmap 7.80 ( https://nmap.org ) at 2020-04-30 14:33 CEST
Nmap scan report for 192.168.3.2
Host is up (0.00026s latency).

PORT    STATE  SERVICE
139/tcp closed netbios-ssn
MAC Address: 04:F0:21:23:31:20 (Compex Systems Pte)

Nmap done: 1 IP address (1 host up) scanned in 0.20 seconds

This seems to suggest that the port 139 is closed, which I think it shouldn’t be.
I tried to open it in the firewall settings:
Excerpt with the rule from:
cat /etc/config/firewall

config rule
    option target 'ACCEPT'
    option name 'Samba'
    option src 'lan'
    option proto 'tcp'
    option dest_port '137 138 139 445'

However that firewall rule doesn’t seem to have any effect. The port is still shown as closed when using nmap.

I spend hours on research for other peoples comments with similar problems and felt like going over every single related samba-troubleshooting-thread on the internet.
But despite how often I restart services or the whole router it doesn’t seem to make any difference.
At this point I’m pulling my hairs out. Is there anyone having any idea as to what I can still do and maybe didn’t yet try?

JardaB · April 30, 2020, 2:24pm

Sharing for NTFS ? https://doc.turris.cz/doc/en/howto/nas

Almin · April 30, 2020, 3:50pm

The file system with which both disks are formatted is btrfs.
Thus I think, that this part doesn’t apply in my case.
Am I wrong?

JardaB · May 2, 2020, 7:36am

chmod 777 -R /srv/share
chmod 777 -R /mnt/shareSSD

Almin · May 3, 2020, 3:56am

I just did that and restarted but still
sudo nmap -p 139 -sT "192.168.3.2"
results in

Starting Nmap 7.80 ( https://nmap.org ) at 2020-05-03 05:50 CEST
Nmap scan report for 192.168.3.2
Host is up (0.00027s latency).
PORT    STATE  SERVICE
139/tcp closed netbios-ssn
MAC Address: 04:F0:21:23:31:20 (Compex Systems Pte)
Nmap done: 1 IP address (1 host up) scanned in 0.16 seconds`

and sudo smbclient -L 192.168.3.2 results is

do_connect: Connection to 192.168.3.2 failed (Error NT_STATUS_CONNECTION_REFUSED)

Thank you for the recommendation, nevertheless!
Any other ideas, maybe?

JardaB · May 3, 2020, 6:37am

Beginner’s advice …When setting up shared directories on the router, you followed the instructions guide in the previous link ? There is no need to manually change the rule in /etc/config/firewall. If you have a problem with the visibility of shared directories from Windows OS stations, you need to try enabling SMB2.
I will mention (for order) NetBIOS over TCP/IP.

Try the procedure again from the ground up

Almin · May 3, 2020, 2:02pm

Short answer: Yes, I followed the instructions guide in the previous link. I know there is nothing said about manually changing the firewall config and I can revert that. I just don’t know how to proceed elseway, as the port that should be open is closed with samba up and running.

Long answer:
I did follow the instructions as much as they were applicable.
Sadly, for the Turris Omnia with the NAS perk and TurrisOS 4.x there are no complete up-to-date instructions to set up Samba/SMB shared directories, so I had to combine new and old documentation.

The drives were mounted using the new Storage Plugin that only started existing with TurrisOS 4 and wasn’t yet available in that form originally back in TurrisOS 3.
For that I followed the new documentation here and it works fine:

The result of that is two disks being formated with btrfs (thus NTFS is irrelvant) and mounted using the Software-RAID implementation of btrfs in the /srv directory. They work fine locally on the machine. I can access them, read and write content. I also, as suggested by JardaB, changed the access rights to 777 recursively. So far, so good.

The new documentation doesn’t however describe the usage of SMB shares, so I followed the old documentation from previous link. I followed every step (leaving out the NTFS section).
I cannot connect with any client from the lan, neither Linux (as previously written) nor Windows (as I now confirmed).
If I open the Windows Explorer and attempt to access \\192.168.3.2\nas an error message window pops up.
It offers a not really helpful diagnostic wizard that says the server doesn’t accept any connections.

The only way I could think of to check whether the samba service on the Turris is actually working is to ssh into the Turris and locally run smbclient -L localhost. That seems to work fine and gives me the expected result as I described in my opening post.

If I use the Windows powershell to check whether SMB2 is enabled, that sems to be the case:

In case the Windows Explorers Network section is supposed to detect the Turris or the SMB share, it doesn’t.

NetBIOS over TCP/IP is activated, as I use a static IPv4 configuration. But I manually checked it now and I wouldn’t have thought of that setting, so thank you!

Any other ideas?

JardaB · May 3, 2020, 3:01pm

SUPER: This is a well-described problem — error number !!! Windows 10 update issue ??

https://www.dell.com/support/article/cs-cz/sln317405/dell-fluidfs-customer-notification-unable-to-access-shares-after-updating-to-windows-10-v1903-using-smb-3-1-1?lang=en

Citation: After performing a Microsoft Windows update on systems running Windows 10 version 1903 or Windows Server version 1903, Windows clients using SMB 3.1.1 lose access to SMB Shares after Microsoft Windows Update to version 1903 on Windows 10.

This issue is due to two negotiation contexts found in SMB 3.1.1 that FluidFS version 6.0.300135 and lower does not support. followed by a solution to the error

JardaB · May 3, 2020, 3:13pm

Almin · May 3, 2020, 4:32pm

I indeed didn’t think of checking out the error number. Thank you so much for you help and efforts!
After looking around and trying some of the solution aproaches out, none of them solved it.
I’m not so sure that it’s actually a Windows Client problem.
I also can’t connect from a Linux client and that should be possible as well.
And I wonder why the port 139/tcp is still closed – should that port really be closed with samba running?
After all, I can’t blame any operating system for not being able to connect as client to a server via a closed port.
That leads me to think it might rather be a server-side issue, that I made some mistake in the server setup/configuration or maybe it’s even a bug.
It’s just, I went over the documentation at least 6 times now and I’m pretty damn sure I didn’t miss anything.

Almin · May 3, 2020, 5:19pm

Ah, by the way, I can connect to another SMB share, that I have in my network. So the clients are not at fault, unless I need to configure them in a special way to also work with the Turris. Thus, I’m pretty sure the problem is with the server.

JardaB · May 3, 2020, 6:17pm

Nothing easier if you think the problem is in Omnia router settings, I can send you a configuration file and what you say …

Almin · May 4, 2020, 1:38am

That would be awesome! If it works for you I have at least a comparison to a working configuration. Which version of Turris OS / OpenWRT are you using?

JardaB · May 5, 2020, 5:41pm

My OS version 3.11.16

Maxmilian_Picmaus · May 5, 2020, 11:22pm

I’ve some notes : Maxovy poznamky k smb.conf (it is in CZ, maybe i will translate it to ENG).

ad_win10: windows are using latest samba version and protocols, meanwhile TOS is using 3.6 version. TOS can loose election to “samba master” and win10 can win, in that case, shares won’t work.
ad_firewall: you should first check sharing option for your workgroup and assign it to some network you have (public,home,private…) and later allow samba ports just for that network

note: there are also “min/max protocol” options which manage what will be used. SMB1,SMB2,SMB3 (it is not related to samba version), where it is recommended to use SMB2 as max (so smb1 and 2 will be used). Samba 3.6 use SMB2(resp. SMB2_10), Samba4.x use SMB3(SMB3_11) which is default on win10. more info: https://accedian.com/enterprises/blog/troubleshooting-smb-performance/
note2: regarding the ports …each dialect uses different ports, and if you have min=smb1 and max=smb2 (or smb3) you never know what dialect is used by each client.
SMB1 >> UDP: 137,138 TCP:139,445
SMB2 >> UDP: TCP:445

ad_master: there are “master” + “os level” options in smb.conf where you can force TOS be domain/preffered/local master

Almin · May 12, 2020, 8:45pm

IT WORKS!!! IT FREAKING WORKS!!! WOOOOHOOOOOO!!!

Thank you for the input, using nmap again I checked and realized both ports 137 and 138 on UDP are open.

PORT STATE SERVICE
137/udp open|filtered netbios-ns
138/udp open|filtered netbios-dgm

Meanwhile TCP ports 139 and 445 are closed. Didn’t work.
I got frustrated like incredible and was incredibly close to just dumping that crap alltogether (out the window, first the Turris, then me head first through the glass).
Randomly followed some instructions, opening just all the ports, making random changes to the configuration, no idea what I’m doing.
The last documentation I followed was that one here:

And now it incredibly freaking works!

I have no idea which exact step it was, or whether the pantheon of gods just felt sorry for my pathetic attempts and just took pity and made it work, but here I will describe my current state of config, in case anyone else might profit from it:

In Luci my Shares configuration template looks as follows:

[global]
netbios name = |NAME| 
display charset = |CHARSET|
interfaces = |INTERFACES|
server string = |DESCRIPTION|
unix charset = |CHARSET|
workgroup = |WORKGROUP|
deadtime = 30
domain master = yes
enable core files = no
guest account = nobody
local master = yes
guest okay = yes
map to guest = Bad User
max protocol = SMB2
min receivefile size = 16384
null passwords = yes
passdb backend = smbpasswd
security = user
smb passwd file = /etc/samba/smbpasswd
use sendfile = yes

In Luci Shares general settings tab the config is set to as follows:
Hostname: TurrisNAS
Description: OpenWrt
Work group: <<Left it empty, so falls back to default WORKGROUP>>

I have one Share/Directory set up and working:
name: nas
path /srv/nas
legimitated users: <<Left it empty, no idea what the system is making of it>>
read only: <<Left unchecked, I also wanna write after all>>
guest access: Checked, dunno what happens if I uncheck it, maybe I’ll unleash the wrath of the gods.
Mask for new files: 0644 (Whatever, it works, seemingly, don’t know, better not touch)
Mask for new directories: 0755 (The same)

In Luci, in the firewall section, under traffic rules, I added a new rule.
I gave it the name Samba and basically allowed all the ports 137,138,139,445 on both tcp and udp in “lan” (from every PC to every PC).

I know this is probably not optimal, but for now, feeling like the master of the universe, I’m not gonna worry about the safety or robustness of my configuration but enjoy this moment of glory.
With tears in my eyes, singing and dancing, because Samba works.
Loving you all.
Good night.
Goes sleeping with an evil grin

Maxmilian_Picmaus · May 13, 2020, 6:15pm

Glad you 've make it working
I totally understand your feeling, … IT WORKS , I MADE IT WORK, HEUREKA!!!, now i can cut the trees with bare hands

EDIT: before i do the translation in my CZ post…some notes (i tried to keep it simply, but i am sometimes tooo chatty

workgroup

once you have it working, change the default workgroup name to something else. That will prevent any client/server to overtake the “master” from the TOS and in combination with “guest” it is kind of unsecure (as any client with windows default setup might see your shares)

dialect

if you set the max, it is good to use also min (if you are not using some devices with obsolete Samba clients you can use SMB2 as min and max for most scenarios. If you upgrade to Samba 4.x on TOS you can use min=SMB2 and max=SMB3 (so you can benefit from new dialect and that will reduce amount of open ports, SMB1 is kind of obsolete nowadays (due that netbios layer)

read vs write options

“readonly=yes” together with “writeable=no” in “general” section is fine, it should work. You just have to set individually each share for write/read. (which is , better as you have option to have each share folder setup individually. Reverse setup is also fine, but, but you should consider situation when “share” section is not loaded/applied and “general” options is.

permissions

regading mask for new files. It is better to set it (there is default anyway, which might not suit you well) for example 644 in samba world is mask 113 in unix world causing chmod 664 on file. “dir_mask” (samba mask), “create_mask”(unix permission)
https://www.samba.org/samba/docs/using_samba/figs/sam2_0802.gif

guest

guest, you should set it to NO, do not use guest at all(possible security breach). Somehow “guest” is threated differently, you should set some real unix user and sync it with samba (via smbpasswd,smbpwd…or similar tool)
i faced situation when guest was used and i was able to traverse whole filesystem freely (i was able to list any folder – so if you have readonly you are safe, if writeable=yes, such guset user can try to write/remove some files … )

forced_user

if you have some dedicated samba user (not running it under nobody/nogroup), set that user to be “forced_user” so all files/folders are owned by that user:group. To allow other users to access the files, add them simply to same group (in my case “users”)

legit/invalid users

legitimate users, there you list all unix users which are also samba users (having smbpasswd synced/set). there is also “invalid users” where you specify users without any access to smb (so it is wise to put “root” there)

EDIT2: i made draft translation of my notes(for now just initial post, rest will follow soon) : Maxmilian's notes on smb.conf

Almin · May 14, 2020, 10:33am

So first of all, I don’t feel like needing hands for that anymore, now! It’s all just a mind-thing, really!

My config so far was way from perfect or good, especially not safe or secure user access right vise.
At this point I’m just honestly grateful it works at all.

Dialect

Dialect minimum seems to be SMB2_02. If I use smbclient --max-protocol=SMB2_02 ... it works, so at least that protocol version seems to work fine. If I deliberatly try to set smbclient --max-protocol=NT1 -L 192.168.x.y I receive

lp_load_ex: Max protocol NT1 is less than min protocol SMB2_02.
protocol negotiation failed: NT_STATUS_INVALID_PARAMETER_MIX

By the way, name resolution doesn’t seem to work. I set the Hostname in the luci-samba frontend to TurrisNAS. This causes /etc/samba/smb.conf to contain:

[global]
netbios name = TurrisNAS

I think that should be the equivalent to your post:
netbios name = XXXXXXXXX ## network name "netview" --> \\XXXXXXX\MyShare
If I use the IP like smbclient -L 192.168.x.y it works fine. If I instead use smbclient -L TurrisNAS I get the good old useless do_connect: Connection to TurrisNAS failed (Error NT_STATUS_NOT_FOUND)

Regarding permissions. For testing purpose I still have it extremely liberal

Thanks for all the help I received! From here on forward, I will now work on tightening the restrictions to make it a safer configuration. Step by step, each time checking whether it still works.
For that, your in-depth comment on the security of the configuration helps me a lot! So thank you A LOT for that!

Unless there is any more things to learn for other users facing smb/samba configuration issues I would now gratefully stop writing further messages in this section. After all, the original set-up failure I had is now solved. So further in-depth configuration discussions should rather move to the thread that you started with your notes on smb.conf.