TS-439 Pro Windows clients lost SMB shares

Windows Access Rights Management
Post Reply
User avatar
kkimmell
Starting out
Posts: 17
Joined: Tue Dec 22, 2009 3:53 am

TS-439 Pro Windows clients lost SMB shares

Post by kkimmell »

I have been reading a variety of other threads that range from extremely similar to peripherally similar to the problem that has cropped up in our situation in the past week. We pinned the problem's initial appearance down to a fairly small window of a few hours last week. In that time frame the main thing that happened when considering the machines that matter is that I allowed my QNAP TS-439 Pro which was running 4.2.6 (20170628) to upgrade to 4.2.6 (20170729) from the gui.

We have a build machine that is running Windows 10 that pulls from our code repository frequently to look for changes. When it sees new code checked in it pulls the changes and runs a build process to give our testers new versions of various projects to test. This entire process is handled in a java container using the localsystem account. I'm not sure that's relevant, just trying to be complete in my assessment. We recently had all users turn off the Windows 10 feature for SMB1.0/CIFS File Sharing support due to the security implications and the fact that Microsoft wont be removing it by force until the Fall update.

So onto the problem. The NAS that we names FileSpot stopped showing up in network browses. The build machine could still get to the share via UNC using either the name or the IP but browsing to it was a problem. I hadn't rebooted my Win10 machine yet even though I turned SMB1/CIFS off and I *could* still browse. After a reboot... no longer. On it's own this wouldn't be a problem as I've mapped my users to an N drive and that was working. For whatever reason, the localsystem java process fails and I can see from logs that it's failing to create directories on FileSpot and therefore can't copy the new code over to the shared folder.

For the last few days after reading other threads I've been through so many iterations of trial an error to get it back to the way it was that my head is starting to spin. My first step was to check what level of SMB was running on the server and smb2status reported "max protocol SMB 2.0" which Windows 10 is perfectly capable of. So next, after a backup, I used the manual process to roll us back to build 20170628 which is where we currently stand but the problems persist. I read that perhaps the smb.conf could have been effected in the upgrade and not in the downgrade but I don't see anything in particular. I will include it here with the main "global" section and the pertinent share section:

Code: Select all

[global]
workgroup = DYNAMIC
security = USER
server string = FileSpot
	encrypt passwords = Yes
username level = 0
	map to guest = Bad User
null passwords = yes
	max log size = 10
socket options = TCP_NODELAY SO_KEEPALIVE
os level = 20
preferred master = no
	dns proxy = No
	smb passwd file=/etc/config/smbpasswd	
	username map = /etc/config/smbusers
	guest account = guest
	directory mask = 0777
	create mask = 0777
oplocks = yes
	locking = yes
disable spoolss = no
	load printers = no
veto files = /.AppleDB/.AppleDouble/.AppleDesktop/:2eDS_Store/Network Trash Folder/Temporary Items/TheVolumeSettingsFolder/.@__thumb/.@__desc/:2e*/.@__qini/.Qsync/.@upload_cache/.qsync/.qsync_sn/.@qsys/.digest/
	delete veto files = yes
map archive = no
map system = no
map hidden = no
map read only = no
deadtime = 10
use sendfile = yes
case sensitive = auto
unix extensions = no
wins support = yes
store dos attributes = yes
client ntlmv2 auth = yes
dos filetime resolution = no
inherit acls = no
wide links = yes
force unknown acl user = yes
template homedir = /share/homes/DOMAIN=%D/%U
domain logons = no
min receivefile size = 8192
domain master = auto
local master = yes
passdb backend = smbpasswd
enhance acl v1 = yes
remove everyone = no
kernel oplocks = no
mangled names = yes
printcap cache time = 0
conn log = no
max protocol = SMB2
pid directory = /var/lock
host msdfs = yes
server role = auto
acl allow execute always = yes
display charset = UTF8
name resolve order = wins host bcast

[NETDUMP]
comment = Our Files
path = /share/MD0_DATA/NETDUMP
browsable = yes
oplocks = yes
ftp write only = no
recycle bin = yes
recycle bin administrators only = yes
public = yes
invalid users = 
read list = 
write list = "admin",@"everyone","guest"
valid users = "root","admin",@"everyone","guest"
inherit permissions = yes
mangled names = yes
qbox = no
So becasue this process is integral to our business I had to come up with a solution in the short term and so far what I've found is the only way to get our process to work is to set the NAS to use SMB1 and to turn SMB1/CIFS back on on that build machine. In the long term this isn't acceptable. I don't know how this firmware update could have done this but I am really scratching my head trying to get a solution. I know our NAS is old but this just seems strange. Can anyone see a problem in the SMB file? Anywhere else to look?

Thanks,
kk
User avatar
schumaku
Guru
Posts: 43578
Joined: Mon Jan 21, 2008 4:41 pm
Location: Kloten (Zurich), Switzerland -- Skype: schumaku
Contact:

Re: TS-439 Pro Windows clients lost SMB shares

Post by schumaku »

Most what you have read here (there was a problem with the NetBIOS host announcement and name resolution mainly on Marvell Kirkwood ARM based systems) can't be relevant for the TS-439 Pro.

The testparms output looks a little bit short, or you have just posted one shard folder.
kkimmell wrote:We recently had all users turn off the Windows 10 feature for SMB1.0/CIFS File Sharing support due to the security implications and the fact that Microsoft wont be removing it by force until the Fall update.

So onto the problem. The NAS that we names FileSpot stopped showing up in network browses.
If you had removed the CIFS/SMB 1.0 feature form Widnwos 10, you have removed the NetBIOS nane resolution, too. For the host announcement, NetBIOS is still core when operating SAMBA systems. If this is not the case, continue reading.

Big difference from 4.2.6 (20170628) to upgrade to 4.2.6 (20170729) to is that a SAMBA 4 is in place now.

To start with, enable SMB 2.1 and shot the complete transcript:

[~] # smb21enable
...

(done automatically is [~] # /etc/init.d/smb.sh restart )

And then, to gain some more insight:

[~] # cat /var/log/log.smbd
...

[~] # cat /var/log/log.nmbd
...

Typical cause are modded smb.conf, bad guest account mapping, or a removed guest account from /etc/passwd
Last edited by schumaku on Thu Aug 10, 2017 12:47 am, edited 1 time in total.
Reason: mishap
User avatar
kkimmell
Starting out
Posts: 17
Joined: Tue Dec 22, 2009 3:53 am

Re: TS-439 Pro Windows clients lost SMB shares

Post by kkimmell »

I'm still running the older firmware since the rollback... I can update again if that makes this move in a better direction. I will add that my temporary solution for the build machine has progressed in that I have the java app running as via a local admin account instead of localsystem so that has allowed me to run the smb21enable and still be able to build.

Code: Select all

# smb21enable
Shutting down SMB services: smbd nmbd.
Shutting down winbindd services: winbindd.
max protocol SMB 2.1 ... enabled.
locks path was set to /share/MD0_DATA/.locks
Shutting down winbindd services: winbindd.
Starting winbindd services:Starting SMB services:.

smbd (samba daemon) Version 3.6.25
smbd (samba daemon) is running.
max protocol SMB 2.1 enabled.
smbd.log from the point of the last restart:

Code: Select all

[2017/08/09 13:35:37,  0] smbd/server.c:1261(main)
  smbd version 3.6.25 started.
  Copyright Andrew Tridgell and the Samba Team 1992-2011
[2017/08/09 13:35:37,  0] param/loadparm.c:8153(lp_do_parameter)
  Ignoring unknown parameter "server role"
[2017/08/09 13:35:37,  0] param/loadparm.c:8153(lp_do_parameter)
  Ignoring unknown parameter "acl allow execute always"
[2017/08/09 13:35:37.594314,  0] param/loadparm.c:8153(lp_do_parameter)
  Ignoring unknown parameter "server role"
[2017/08/09 13:35:37.594536,  0] param/loadparm.c:8153(lp_do_parameter)
  Ignoring unknown parameter "acl allow execute always"
Same thing for nmbd.log

Code: Select all

[2017/08/09 13:35:39,  0] nmbd/nmbd.c:864(nmbd_main)
  nmbd version 3.6.25 started.
  Copyright Andrew Tridgell and the Samba Team 1992-2011
[2017/08/09 13:35:39,  0] param/loadparm.c:8153(lp_do_parameter)
  Ignoring unknown parameter "server role"
[2017/08/09 13:35:39,  0] param/loadparm.c:8153(lp_do_parameter)
  Ignoring unknown parameter "acl allow execute always"
[2017/08/09 13:35:39.681043,  0] param/loadparm.c:8153(lp_do_parameter)
  Ignoring unknown parameter "server role"
[2017/08/09 13:35:39.681267,  0] param/loadparm.c:8153(lp_do_parameter)
  Ignoring unknown parameter "acl allow execute always"
[2017/08/09 13:35:39.709742,  0] nmbd/nmbd_namequery.c:109(query_name_response)
  query_name_response: Multiple (2) responses received for a query on subnet 10.11.12.5 for name DYNAMIC<1d>.
  This response was from IP 10.11.12.2, reporting an IP address of 10.11.12.2.
The 10.11.12.2 address if a FreeNAS server that hosts backups. If you need more output or would rather I upgrade the firmware let me know. We're in an "okay" place now with builds working and SMB1 disabled on the client machines but I'd certainly like to resolve the network browse functions if possible. Are you saying that Windows in unable to browse samba shares without having SMB1 enabled? That sounds... odd.

Thanks,
kk
User avatar
schumaku
Guru
Posts: 43578
Joined: Mon Jan 21, 2008 4:41 pm
Location: Kloten (Zurich), Switzerland -- Skype: schumaku
Contact:

Re: TS-439 Pro Windows clients lost SMB shares

Post by schumaku »

Well, we need the logs of the apparently non-working config with the new firmware. If you can do this the next two hours and provide the logs, I can have an eye - and worst case you can revert again. Later I need some sleep (Central Europe time zone) :shock:
kkimmell wrote: Are you saying that Windows in unable to browse samba shares without having SMB1 enabled?
No, I don't. I say the Windows 10 CIFS/SMB 1.0 feature does include both SMB 1.0 _and_ the NetBIOS name resolution. Removing this does more than just remove SMB 1.0 - it does remove the NetBIOS name resolution service, too.
User avatar
kkimmell
Starting out
Posts: 17
Joined: Tue Dec 22, 2009 3:53 am

Re: TS-439 Pro Windows clients lost SMB shares

Post by kkimmell »

Ok... in anticipation I've updated to the newer firmware and rebooted. Here are some outputs:

Code: Select all

# smb21enable

smbd (samba daemon) Version 4.0.25
smbd (samba daemon) is running.
max protocol SMB 2.1 enabled.

 # cat /var/log/log.smbd
[2017/08/09 14:15:44,  0] ../source3/smbd/server.c:1367(main)
  smbd version 4.0.25 started.
  Copyright Andrew Tridgell and the Samba Team 1992-2012
[2017/08/09 14:15:44.944858,  0] ../source3/lib/util_sock.c:423(open_socket_in)
  open_socket_in(): socket() call failed: Address family not supported by protocol
[2017/08/09 14:15:44.947615,  0] ../source3/lib/util_sock.c:423(open_socket_in)
  open_socket_in(): socket() call failed: Address family not supported by protocol
[2017/08/09 14:17:44,  0] ../source3/smbd/server.c:1367(main)
  smbd version 4.0.25 started.
  Copyright Andrew Tridgell and the Samba Team 1992-2012
[2017/08/09 14:17:44.128517,  0] ../source3/lib/util_sock.c:423(open_socket_in)
  open_socket_in(): socket() call failed: Address family not supported by protocol
[2017/08/09 14:17:44.137199,  0] ../source3/lib/util_sock.c:423(open_socket_in)
  open_socket_in(): socket() call failed: Address family not supported by protocol
[2017/08/09 14:24:16,  0] ../source3/smbd/server.c:1367(main)
  smbd version 4.0.25 started.
  Copyright Andrew Tridgell and the Samba Team 1992-2012
[2017/08/09 14:24:17.049839,  0] ../source3/lib/util_sock.c:423(open_socket_in)
  open_socket_in(): socket() call failed: Address family not supported by protocol
[2017/08/09 14:24:17.062057,  0] ../source3/lib/util_sock.c:423(open_socket_in)
  open_socket_in(): socket() call failed: Address family not supported by protocol
  
 # cat /var/log/log.nmbd
[2017/08/09 14:17:48,  0] ../source3/nmbd/nmbd.c:885(main)
  nmbd version 4.0.25 started.
  Copyright Andrew Tridgell and the Samba Team 1992-2012
[2017/08/09 14:17:48.699148,  0] ../source3/nmbd/nmbd_namequery.c:109(query_name_response)
  query_name_response: Multiple (2) responses received for a query on subnet 10.11.12.5 for name DYNAMIC<1d>.
  This response was from IP 10.11.12.2, reporting an IP address of 10.11.12.2.
[2017/08/09 14:22:54.180322,  0] ../source3/nmbd/nmbd_namequery.c:109(query_name_response)
  query_name_response: Multiple (2) responses received for a query on subnet 10.11.12.5 for name DYNAMIC<1d>.
  This response was from IP 10.11.12.2, reporting an IP address of 10.11.12.2.
[2017/08/09 14:24:21,  0] ../source3/nmbd/nmbd.c:885(main)
  nmbd version 4.0.25 started.
  Copyright Andrew Tridgell and the Samba Team 1992-2012
[2017/08/09 14:24:21.077470,  0] ../source3/nmbd/nmbd_namequery.c:109(query_name_response)
  query_name_response: Multiple (2) responses received for a query on subnet 10.11.12.5 for name DYNAMIC<1d>.
  This response was from IP 10.11.12.2, reporting an IP address of 10.11.12.2.
[2017/08/09 14:29:28.940351,  0] ../source3/nmbd/nmbd_namequery.c:109(query_name_response)
  query_name_response: Multiple (2) responses received for a query on subnet 10.11.12.5 for name DYNAMIC<1d>.
  This response was from IP 10.11.12.2, reporting an IP address of 10.11.12.2.
[2017/08/09 14:34:28.949515,  0] ../source3/nmbd/nmbd_namequery.c:109(query_name_response)
  query_name_response: Multiple (2) responses received for a query on subnet 10.11.12.5 for name DYNAMIC<1d>.
  This response was from IP 10.11.12.2, reporting an IP address of 10.11.12.2.
[2017/08/09 14:39:28.952983,  0] ../source3/nmbd/nmbd_namequery.c:109(query_name_response)
  query_name_response: Multiple (2) responses received for a query on subnet 10.11.12.5 for name DYNAMIC<1d>.
  This response was from IP 10.11.12.2, reporting an IP address of 10.11.12.2.
[2017/08/09 14:44:29.471247,  0] ../source3/nmbd/nmbd_namequery.c:109(query_name_response)
  query_name_response: Multiple (2) responses received for a query on subnet 10.11.12.5 for name DYNAMIC<1d>.
  This response was from IP 10.11.12.2, reporting an IP address of 10.11.12.2.
[2017/08/09 14:49:28.969155,  0] ../source3/nmbd/nmbd_namequery.c:109(query_name_response)
  query_name_response: Multiple (2) responses received for a query on subnet 10.11.12.5 for name DYNAMIC<1d>.
  This response was from IP 10.11.12.2, reporting an IP address of 10.11.12.2.
[2017/08/09 14:54:28.969105,  0] ../source3/nmbd/nmbd_namequery.c:109(query_name_response)
  query_name_response: Multiple (2) responses received for a query on subnet 10.11.12.5 for name DYNAMIC<1d>.
  This response was from IP 10.11.12.2, reporting an IP address of 10.11.12.2.
[2017/08/09 14:59:28.976294,  0] ../source3/nmbd/nmbd_namequery.c:109(query_name_response)
  query_name_response: Multiple (2) responses received for a query on subnet 10.11.12.5 for name DYNAMIC<1d>.
  This response was from IP 10.11.12.2, reporting an IP address of 10.11.12.2.
[2017/08/09 15:04:28.977930,  0] ../source3/nmbd/nmbd_namequery.c:109(query_name_response)
  query_name_response: Multiple (2) responses received for a query on subnet 10.11.12.5 for name DYNAMIC<1d>.
  This response was from IP 10.11.12.2, reporting an IP address of 10.11.12.2.
[2017/08/09 15:09:28.297943,  0] ../source3/nmbd/nmbd_namequery.c:109(query_name_response)
  query_name_response: Multiple (2) responses received for a query on subnet 10.11.12.5 for name DYNAMIC<1d>.
  This response was from IP 10.11.12.2, reporting an IP address of 10.11.12.2.
[2017/08/09 15:14:28.980169,  0] ../source3/nmbd/nmbd_namequery.c:109(query_name_response)
  query_name_response: Multiple (2) responses received for a query on subnet 10.11.12.5 for name DYNAMIC<1d>.
  This response was from IP 10.11.12.2, reporting an IP address of 10.11.12.2.
[2017/08/09 15:19:28.975371,  0] ../source3/nmbd/nmbd_namequery.c:109(query_name_response)
  query_name_response: Multiple (2) responses received for a query on subnet 10.11.12.5 for name DYNAMIC<1d>.
  This response was from IP 10.11.12.2, reporting an IP address of 10.11.12.2.
  
 # testparm
Load smb config files from /etc/config/smb.conf
rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384)
WARNING: The "null passwords" option is deprecated
Processing section "[Network Recycle Bin 1]"
Processing section "[backups]"
Processing section "[prog]"
Processing section "[NETDUMP]"
Processing section "[home]"
Loaded services file OK.
WARNING: You have some share names that are longer than 12 characters.
These may not be accessible to some older clients.
(Eg. Windows9x, WindowsMe, and smbclient prior to Samba 3.0.)
Server role: ROLE_STANDALONE
In regards to SMB1/CIFS... is keeping that enabled on the Windows client able to be counteracted by somehow disabling SMB1 on the NAS? And if so, that still seems like we'd be leaving a gaping security hole in our clients even if the samba shares were all >= SMB2 - no?

Thanks,
kk
User avatar
schumaku
Guru
Posts: 43578
Joined: Mon Jan 21, 2008 4:41 pm
Location: Kloten (Zurich), Switzerland -- Skype: schumaku
Contact:

Re: TS-439 Pro Windows clients lost SMB shares

Post by schumaku »

That's strange - at this point...

Code: Select all

  smbd version 4.0.25 started.
  Copyright Andrew Tridgell and the Samba Team 1992-2012
[2017/08/09 14:24:17.049839,  0] ../source3/lib/util_sock.c:423(open_socket_in)
  open_socket_in(): socket() call failed: Address family not supported by protocol
[2017/08/09 14:24:17.062057,  0] ../source3/lib/util_sock.c:423(open_socket_in)
  open_socket_in(): socket() call failed: Address family not supported by protocol
...I guess there is no smbd up and listening on the network? Same works here on the only remaining TS-639 Pro, it binds to both IPv4 and IPv6. That might be one for QNAP...

---
kkimmell wrote:In regards to SMB1/CIFS... is keeping that enabled on the Windows client able to be counteracted by somehow disabling SMB1 on the NAS?
I've made a proposal that QNAP does make both the min protocol and max protocol available in the Web UI, and default to a minimum of SMB 2.1 and a max of SMB 3.0 (resp. the SAMBA default). Setting the max protocol to 2.1 or 3.0 does not disable the usage of SMB 1.0 on the NAS.

So ... experimental mood?

Note: This can work with QTS 4.2. 20170729 (on TS-x39, TS-x59, TS509, TS-809, and all Marvell Kirkwood when I'm right) and newer as this comes with SAMBA 4 - remove the line if reverting to earlier firmware:

[~] # setcfg -f /etc/config/smb.conf global "min protocol" SMB2_02
[~] # /etc/init.d/smb.sh restart
Restarting SMB services:
Shutting down SMB services: smbd nmbd.
Shutting down winbindd services: winbindd.
/bin/cp: cannot stat `/etc/default_config/logrotate.conf': No such file or directory <<<<<<<<< reported to QNAP already!
/bin/cp: cannot stat `/etc/default_config/logrotate.d': No such file or directory <<<<<<<<< reported to QNAP already!
locks path was set to /share/MD1_DATA/.locks
Shutting down winbindd services: winbindd.
Starting winbindd services: winbindd.
Starting SMB services:.
done.

Now the NAS should no longer accept or negotiate to any protocol lower than SMB 2.02 anymore.
kkimmell wrote:And if so, that still seems like we'd be leaving a gaping security hole in our clients even if the samba shares were all >= SMB2 - no?
With the CIFS/SMB 1.0 feature in place, and the Microsoft NEtwork File share service in place, also your Windows 10 systems can be reached, and the WIndows 10 system SMB client can still make use of the SMB 1.0 to connect to servers (where no higher protocol is available). A good overview on how to disable SMB 1.0 is -> https://support.microsoft.com/en-us/hel ... nd-windows - however, as explanierend before, the "How to gracefully remove SMB v1 in Windows 8.1, Windows 10, Windows 2012 R2, and Windows Server 2016" does show to remove the feature - which is not an option for now, because the NetBIOS name resolution will be lost, too.
Post Reply

Return to “Windows”