NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Samba doesn't work when accessing by name after upgrade to 6.10
As of the upgrade from 6.9.9, to 6.10, all my backup jobs started failing. I noticed that I could no longer access the NAS by name. I can ping it fine by name. If I go into Windows explorer, the NAS is listed, but when I try to connect to it I get a dialog popping up saying "Windows cannot access \\NAS"...
If I refer to it by IP it works fine. So I have a workaround, but it was a big job changing all my Shadowprotect backup jobs and recreating all the Imagemanager managed folders.
Coincidentally, when I login to the NAS via SSH, it takes ages to give me a prompt, which is indicative of a name server issue, but it has no problems resolving once in.
At first I thought it might be firewall. I removed all the rules iptables -X. It seemed to work, but it must have been coincidental as it stopped working again very soon after.
systemctl status shows the smb and nmb services running fine.
I have customers which updated no problems and my home NAS, a Pro4 upgraded to v6 over a year ago has upgraded with no issues.
The 716 has 4 Ethernet ports. 2 x 1Gig and 2 x 10 Gig. 2 are in use on different subnets. That is about the only difference in config between this and others that work.
Looking back through the /var/lib/samba/log.nmbd, the NAS has been acting as the local master browser for Workgroup on both network interfaces, but since I upgrade on Friday, it is now only acting as a master browser on the iSCSI interface, not the data interface.
When I try to connect to the device to list shares (\\NAS), the /var/log/samba/log.smbd gives me.
[2019/05/01 18:33:13.897005, 1] ../auth/gensec/spnego.c:1218(gensec_spnego_server_negTokenInit_step)
gensec_spnego_server_negTokenInit_step: ntlmssp: parsing NEG_TOKEN_INIT content failed (next[(null)]): NT_STATUS_INVALID_PARAME TER
[2019/05/01 18:33:14.178870, 2] ../auth/ntlmssp/ntlmssp.c:119(gensec_ntlmssp_update_find)
Failed to parse NTLMSSP packet: zero length
[2019/05/01 18:33:14.178935, 1] ../auth/gensec/spnego.c:1218(gensec_spnego_server_negTokenInit_step)
gensec_spnego_server_negTokenInit_step: ntlmssp: parsing NEG_TOKEN_INIT content failed (next[(null)]): NT_STATUS_INVALID_PARAME TER
I see links to this exact issue in Samba. E.G. https://bugzilla.redhat.com/show_bug.cgi?id=1657428
I hope this is enough info for someone to offer a suggestion.
To reiterate. This NAS has been working as-is for the last few years. The only change was the 6.9.10 update.
6 Replies
Replies have been turned off for this discussion
Welcome to the club. Had you searched before posting, you would have found several others (myself included) have this problem. There have been no solutions forthcoming.
My "fix" is to either put the NAS IP in the computer's HOSTS file or just use the IP address.
- I didn't search the forum, but I did search with Google and nothing came up from this forum. Could you link the other thread please? Anyway that is not a fix. I hope netgear are working on a patch as a priority.
Sorry, I don't keep links in my back pocket. There are several, though sometimes hard to pick out from the ones for older NASes where the problem is SMB1. But all you will find is others suffering from the same issue with absolutely no useful advice to truly overcome it, just work-arounds like I have provided.
It doesn't appear to be a ReadyNAS unique issue, as I see similar posts regarding other Linux devices in the Microsoft forums (likelwise, with no real resolution). Since this has been an issue for months, it certainly doesn't look like Netgear is trying to do anything about it. Of course, it also doesn't affect everyone, for some reason.
mdutton wrote:
Coincidentally, when I login to the NAS via SSH, it takes ages to give me a prompt, which is indicative of a name server issue, but it has no problems resolving once in.
Are you operating a DNS server with reverse lookup zones for your (assuming) private RFC1918 subnet? If not, and this does take forever, there are DNS servers configured (for an overview check # cat /etc/resolv.conf) which are either not responding, or responding very slowly. You might have configured some random IP on the iSCSI network (because of the ReadyNAS UI does rant about the missing DNS entries if we don't...) for DNS - which don't exist, or don't serve DNS That would be a plain DNS problem. Not sure what would happen if the new Audit server does run into a problem, e.g. if no more autit trace can be written to the sqlite anymore why ever. "Seriously" secured OS would deny any logins in this situation.
As you seem to have name resolution problems, and talk of nmbd, there is probably no local DNS, also not for a local zone (domain) with A records.
Why on earth still NetBIOS? We're in the year 2019. Still supporting legacy (or with Windows 7 and similar aged Windows Servers - almost legacy) systems? Anway, let's look into this, I'll try - as we don't operate NetBIOS discovery/name resolution on the ReadyNAS anymore - but of course we can enable it for some testing again.
Have some RN with multiple interfaces
mdutton wrote:
Looking back through the /var/lib/samba/log.nmbd, the NAS has been acting as the local master browser for Workgroup on both network interfaces, but since I upgrade on Friday, it is now only acting as a master browser on the iSCSI interface, not the data interface.
Other systems - Windows, U**x/SAMBA, ...) can act as a master browser on any LAN. And each LAN (at least where SAMBA is bind to - why ever it is on the ReadyCloud/LeafNet...) requires a master browser.
We have some RN with interfaces - phsyical, bonded, VLANs, .... - networks with Internet access, isolated networks without Internet and virtually no global services. On all interfaces, the NetBIOS name discovery is working, one system on these LAN is making the election to become master brower, and the names can be resolved, the RN can be accessed using SMB protocol.
Back to WSD - or better forward to WSD again.
Netgear had added WSD on earlier RN OS releaes already, and it was and is enabled by default along wth SAMBA when I have it right.
If operating modern Windows systems, and your systems won't discover the ReadyNAS using WSD, you might have network devices (L2 or L3) blocking WSD multicast address, 239.255.255.250, protocol UDP.
mdutton wrote:
When I try to connect to the device to list shares (\\NAS), the /var/log/samba/log.smbd gives me. ...
[2019/05/01 18:33:13.897005, 1] ../auth/gensec/spnego.c:1218(gensec_spnego_server_negTokenInit_step)
gensec_spnego_server_negTokenInit_step: ntlmssp: parsing NEG_TOKEN_INIT content failed (next[(null)]): NT_STATUS_INVALID_PARAME TER
[2019/05/01 18:33:14.178870, 2] ../auth/ntlmssp/ntlmssp.c:119(gensec_ntlmssp_update_find)
Failed to parse NTLMSSP packet: zero length
[2019/05/01 18:33:14.178935, 1] ../auth/gensec/spnego.c:1218(gensec_spnego_server_negTokenInit_step)
gensec_spnego_server_negTokenInit_step: ntlmssp: parsing NEG_TOKEN_INIT content failed (next[(null)]): NT_STATUS_INVALID_PARAME TERAt this point, the name resolution has worked. Unclear on what SMB client is involved here.
schumaku wrote:
Are you operating a DNS server with reverse lookup zones for your (assuming) private RFC1918 subnet? If not, and this does take forever, there are DNS servers configured (for an overview check # cat /etc/resolv.conf) which are either not responding, or responding very slowly. You might have configured some random IP on the iSCSI network (because of the ReadyNAS UI does rant about the missing DNS entries if we don't...) for DNS - which don't exist, or don't serve DNS That would be a plain DNS problem. Not sure what would happen if the new Audit server does run into a problem, e.g. if no more autit trace can be written to the sqlite anymore why ever. "Seriously" secured OS would deny any logins in this situation.
As you seem to have name resolution problems, and talk of nmbd, there is probably no local DNS, also not for a local zone (domain) with A records.
Yes I have an internal DNS server. It is an active directory network. The reverse lookup zone is there and there is a record for the NAS. The NAS points to the DCs with the DNS servers.
Other systems - Windows, U**x/SAMBA, ...) can act as a master browser on any LAN. And each LAN (at least where SAMBA is bind to - why ever it is on the ReadyCloud/LeafNet...) requires a master browser.
Yes it actually makes sense that only the iSCSI interface would be a master browser as no other host on the iSCSI network would be bound to SMB networking. There will be other machines doing the role in the data network. DCs have the highest priority and there are 2.
Back to WSD - or better forward to WSD again.
Netgear had added WSD on earlier RN OS releaes already, and it was and is enabled by default along wth SAMBA when I have it right.
If operating modern Windows systems, and your systems won't discover the ReadyNAS using WSD, you might have network devices (L2 or L3) blocking WSD multicast address, 239.255.255.250, protocol UDP.
I wouldn't use WSD in a domain environment. That is a SOHO mechanism.
At this point, the name resolution has worked. Unclear on what SMB client is involved here.
I am using a mixture of Windows clients. Windows 10, Windows 7, 2019, 2016, 2012R2, 2012 and 2008R2. All have the same issue. It is definitely a problem in the SAN.
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
