Unable to access shared folders since firmware 4.3.3 update

[eggfish]

I have a TS212 (called HAL), which I have set up with a few shared folders, and enabled Microsoft Networking so that I could access them from my Windows machines (Win 7 & Win 10). This has been working fine until I updated the NAS firmware to v4.3.3 today, after which I can no longer access my mapped drives, nor can I see the NAS in Windows 10 explorer as a 'computer' (although it shows as 'storage'). If I type \\HAL into the address box of Windows explorer I receive "Windows cannot access \\HAL. Check the spelling of the name. Otherwise there might be a problem with your network. etc" - although I do hear a little disk activity initially?

Running QNAP Finder Pro on Win 10 I see the device, same IP address and subnet. I tried to click 'network drives' but nothing happens. I tried to use the 'map network drive' feature: it brings up an auth challenge box where I enter admin credentials that I use to log in to the NAS web interface. At this point I receive the message "Cannot log in to the device and shared folder. Please check the network connection or username and password, and make sure the device has been started".

After reading information on the net I tried a few things:
- allow Windows 10 to connect to a SAMBA share without requiring encryption (registry setting): this did not work
- I shelled into the box and checked the SAMBA version, which seems to have been updated to 4.x, I read that Windows 10 does not support SAMBA 4 so I tried to set the maximum version in the NAS web interface as described in a post, however that setting no longer exists in this version
- downgraded the firmware to v4.2.5 again (tells me it is running SAMBA v3.6.25 is running with max protocol 1.0 enabled)

I cannot access any shares from my Windows 7, Windows 10 machines, nor from the file manager on my Android - all which used to have mapped drives that could connect.

I'm now stuck and would really appreciate some pointers from the community.

Many thanks in advance for any suggestions.

[ensignvorik]

Can you ping HAL?

Can you access the shares via \\IPADDRESS as opposed to it's hostname.

[eggfish]

Thanks for the quick response.
- I can ping HAL with local IP address 192.168.x.y
- when I typed the local ip into the explorer address bar with \\192.168.x.y I initially got a Windows Security authentication challenge, which I entered administrator credentials into, after which I received the same "Windows cannot access \\192.168.x.y. Check the spelling of the name etc".
... which is different if I type in \\HAL - that just gives me the network error dialogue.
Does that give you any clues?
Thanks again.

[schumaku]

- allow Windows 10 to connect to a SAMBA share without requiring encryption (registry setting): this did not work

there is nothing to tweek or modify on Windows 10. Undo any mods.

- I shelled into the box and checked the SAMBA version, which seems to have been updated to 4.x, I read that Windows 10 does not support SAMBA 4 so I tried to set the maximum version in the NAS web interface as described in a post, however that setting no longer exists in this version

Lot of nonsense in the net. Of course Windows 10 can work with SAMBA 4 - what is a software version, nothing the Windows system has to know about to to be tweeked. The SMB max version control in the Web UI advanced options has never existed on these "cat1" NAS systems. You have to use the shell - there are ready made alias available, like smb2status, smb21enable, smb3enable, smb2disable

Permitting you have SAMBA 4 and QTS 4.3.3 in place - do this:

[~] # smb2status
smbd (samba daemon) Version 4.4.9
smbd (samba daemon) is running.
max protocol SMB 1.0 enabled.

[~] # smb3enable
smbd (samba daemon) Version 4.4.9
smbd (samba daemon) is running.
max protocol SMB 3.0 enabled.

- downgraded the firmware to v4.2.5 again (tells me it is running SAMBA v3.6.25 is running with max protocol 1.0 enabled)

This will reliably kill the SAMBA access, because the update to 4.3.3 does modify the SAMBA configuration to the requirements of SAMBA 4 - the previous SAMBA 3.x will not run on this config anymore.

For now - no other way but to update the NAS to QTS 4.3.3 again ... and then figure out what does break the shared folder access. This can be something "old" messing up the config, prohibiting the access. Or the name resolution might or might not work.

Assuming the symlinks exist ...

[~] # ls /share/ -als | grep Public
0 lrwxrwxrwx 1 admin administ 15 Apr 17 13:13 Public -> HDA_DATA/Public/

...so HDA or MD0 is ok here...

[~] # cd /share/Public

[~] # cd /share/Public
[/share/Public] # wget https://eu1.qnap.com/Storage/TS-212TurboNAS/TS-212_20170413-4.3.3.0154.zip
--2017-04-24 22:28:46-- https://eu1.qnap.com/Storage/TS-212TurboNAS/TS-212_20170413-4.3.3.0154.zip
Resolving eu1.qnap.com... 80.74.156.130
Connecting to eu1.qnap.com|80.74.156.130|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 174825148 (167M) [application/zip]
Saving to: ‘TS-212_20170413-4.3.3.0154.zip’

TS-212_20170413-4.3.3.0154.zip 100%[==================================================================>] 166.73M 1.08MB/s in 2m 56s

2017-04-24 22:31:43 (969 KB/s) - ‘TS-212_20170413-4.3.3.0154.zip’ saved [174825148/174825148]

Check the md5sum (available from the download page)

[/share/Public] # md5sum TS-212_20170413-4.3.3.0154.zip
1831b97c4d75ec75886e1a416570f979 TS-212_20170413-4.3.3.0154.zip

[/share/Public] # unzip TS-212_20170413-4.3.3.0154.zip
Archive: TS-212_20170413-4.3.3.0154.zip
inflating: TS-212_20170413-4.3.3.0154.img

Now follow -> wiki.qnap.com/wiki/Manually_Updating_Firmware

Reboot.

Check the name resolution works:

C:\> ping hal
...

Check one nmbd and some smbd is up and running:

[/share/Public] # ps -ef | grep mbd
4467 admin 924 S /usr/local/samba/sbin/smbd -l /var/log -D -s /etc/config/smb.conf
4471 admin 408 S /usr/local/samba/sbin/smbd -l /var/log -D -s /etc/config/smb.conf
4472 admin 612 S /usr/local/samba/sbin/smbd -l /var/log -D -s /etc/config/smb.conf
13738 admin 1208 S /usr/local/samba/sbin/nmbd -l /var/log -D -s /etc/config/smb.conf
18736 admin 576 S grep mbd

Run testparm ...:

[/share/Public] # 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 "[Download]"
...
Loaded services file OK.
WARNING: socket options = TCP_NODELAY SO_KEEPALIVE SO_SNDBUF=65536 SO_RCVBUF=65536
This warning is printed because you set one of the
following options: SO_SNDBUF, SO_RCVBUF, SO_SNDLOWAT,
SO_RCVLOWAT
Modern server operating systems are tuned for
high network performance in the majority of situations;
when you set 'socket options' you are overriding those
settings.
Linux in particular has an auto-tuning mechanism for
buffer sizes (SO_SNDBUF, SO_RCVBUF) that will be
disabled if you specify a socket buffer size. This can
potentially cripple your TCP/IP stack.

Getting the 'socket options' correct can make a big
difference to your performance, but getting them wrong
can degrade it by just as much. As with any other low
level setting, if you must make changes to it, make
small changes and test the effect before making any
large changes.

Server role: ROLE_STANDALONE

Press enter to see a dump of your service definitions

# Global parameters
[global]
...

[scsirob]

...
Permitting you have SAMBA 4 and QTS 4.3.3 in place - do this:

[~] # smb2status
smbd (samba daemon) Version 4.4.9
smbd (samba daemon) is running.
max protocol SMB 1.0 enabled.

[~] # smb3enable
smbd (samba daemon) Version 4.4.9
smbd (samba daemon) is running.
max protocol SMB 3.0 enabled.

That was the exact issue I had and this fixed it. Thank you!
Why does an upgrade not set the highest available protocol support? Mere mortal end-users will never find this unless they happen to know about this forum.

[schumaku]

That was the exact issue I had and this fixed it. Thank you!

So your Windows 10 system failed to work on SMB 1.0 ... the default that worked before on QTS 4.2.x? A kind of "standard" Windows 10 system does have the SMB/CIFS 1.0 protocol support enabled in the Windows features ... the same is used for the NetBIOS name resolution otherwise not working.

Why does an upgrade not set the highest available protocol support?

DOn't know. Basically the default SMB 1.0 should continue work. But we all know that SMB2.1 does work much better on higher latency connections like a VPN, and SMB 3.0 does allow to support Jumbo Frames with ease.

[scsirob]

So your Windows 10 system failed to work on SMB 1.0 ... the default that worked before on QTS 4.2.x? A kind of "standard" Windows 10 system does have the SMB/CIFS 1.0 protocol support enabled in the Windows features ... the same is used for the NetBIOS name resolution otherwise not working.

SMB1 support seems to have been disabled in a cumulative Windows 10 update back in September of 2016: https://support.microsoft.com/en-us/kb/3185614
This hit some QNAP users back then as well: viewtopic.php?t=125946

Why does an upgrade not set the highest available protocol support?

DOn't know. Basically the default SMB 1.0 should continue work. But we all know that SMB2.1 does work much better on higher latency connections like a VPN, and SMB 3.0 does allow to support Jumbo Frames with ease.

That may mean that my Windows 10 desktop already used SMB 2.x to speak with my previous QNAP firmware version. I'm not going to roll it back to try.
The sensible thing for QNAP to do would be to set SMB support to at least 2.x by default and not limit it to an already deprecated SMB 1.0

[schumaku]

SMB1 support seems to have been disabled in a cumulative Windows 10 update back in September of 2016: https://support.microsoft.com/en-us/kb/3185614

There is no word that SMB1 support was disabled. The only impact of this security fix was that a non-authenticated access to shared folders configured to "guest" access can not be accessed (some talk of map or mount) without providing valid user credentials - being the ones used for the desktop login, credentials stored in the Windows user credentials manager.

When considering that Windows 10 does by default, and for good reasons, not allow accessing shared folders without authentication - regardless of the SMB protocol - it's time about re-thinking re-planing the non-authenticated access to shard folders in anyone's network.

Glad your NAS is workable, and we all have got a current SAMBA with decent protocol support for the remaining life span of the large amount of QNAP Marvell Kirkwood based units in the field.

Regards,
-Kurt.

[eggfish]

Kurt
Thank you very much for your help.
Updating the firmware to latest plus enabling samba 3 last night as you described did the trick, I could access the shares.

Strangely, this morning I was unable to access by name 'hal' (could use IP address), but looking at the the processes with

Code: Select all

ps waux  | grep mbd

I could not see nmbd, so it must have fallen over in the night ...

I restarted samba with

Code: Select all

/etc/init.d/smb.sh restart

and nmbd came up so I could access by name again. I had a look at the smb.conf but couldn't see anything nefarious, will just keep an eye on it in case nmbd falls over again.

Incidentally (for anyone else reading) I flushed the name cache on the windows machine in an adminstrative command window with

Code: Select all

nbstat -RR

- not sure if that was required or helped.

Once again thanks Kurt, it's people like you who help people like me learn something new each day.

[schumaku]

Strangely, this morning I was unable to access by name 'hal' (could use IP address), but looking at the the processes ... I could not see nmbd, so it must have fallen over in the night ..

Not good. Let' shave an eye in the nmbd log file:

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

Let's see if we spot something obvious.

[scsirob]

Something is still fishy.. I make it a habit to reboot a system after a parameter change, to check if things come up OK. When I rebooted, I couldn't get access by name again.

Code: Select all

[~] # ps waux  | grep mbd
 5158 admin       364 S   /usr/local/samba/sbin/smbd -l /var/log -D -s /etc/con
 5162 admin       404 S   /usr/local/samba/sbin/smbd -l /var/log -D -s /etc/con
 5163 admin       336 S   /usr/local/samba/sbin/smbd -l /var/log -D -s /etc/con
 5172 admin       388 S   /usr/local/samba/sbin/smbd -l /var/log -D -s /etc/con
10551 admin      1308 S   /usr/local/samba/sbin/smbd -l /var/log -D -s /etc/con
14811 admin       576 R   grep mbd

And:

Code: Select all

[/var/log] # cat log.smbd
[2017/04/25 20:23:30.286698,  0] ../lib/util/become_daemon.c:124(daemon_ready)
  STATUS=daemon 'smbd' finished starting up and ready to serve connections
[2017/04/25 20:23:30.309884,  0] ../source3/lib/util_sock.c:334(open_socket_in)
  open_socket_in(): socket() call failed: Address family not supported by protocol
[2017/04/25 20:23:30.314045,  0] ../source3/lib/util_sock.c:334(open_socket_in)
  open_socket_in(): socket() call failed: Address family not supported by protocol
[/var/log] # cat log.nmbd
[2017/04/25 20:21:57.642250,  0] ../lib/util/become_daemon.c:135(daemon_status)
  STATUS=daemon 'nmbd' : No local IPv4 non-loopback interfaces available, waiting for interface ...NOTE: NetBIOS name resolution is not supported for Internet Protocol Version 6 (IPv6).
[2017/04/25 20:22:08.834143,  0] ../lib/util/become_daemon.c:124(daemon_ready)
  STATUS=daemon 'nmbd' finished starting up and ready to serve connections
[2017/04/25 20:22:20.249909,  0] ../source3/nmbd/nmbd.c:58(terminate)
  Got SIGTERM: going down...
[2017/04/25 20:22:20.696616,  0] ../lib/util/pidfile.c:146(pidfile_unlink)
  Failed to delete pidfile /var/lock/nmbd.pid. Error was No such file or directory
[2017/04/25 20:22:20.964832,  0] ../lib/util/become_daemon.c:124(daemon_ready)
  STATUS=daemon 'nmbd' finished starting up and ready to serve connections
[2017/04/25 20:22:31.836249,  0] ../source3/libsmb/nmblib.c:873(send_udp)
  Packet send failed to 169.254.255.255(138) ERRNO=Invalid argument
[2017/04/25 20:22:33.866233,  0] ../source3/libsmb/nmblib.c:873(send_udp)
  Packet send failed to 169.254.255.255(138) ERRNO=Invalid argument
[2017/04/25 20:22:35.886238,  0] ../source3/libsmb/nmblib.c:873(send_udp)
  Packet send failed to 169.254.255.255(138) ERRNO=Invalid argument
[2017/04/25 20:22:35.886828,  0] ../source3/libsmb/nmblib.c:873(send_udp)
  Packet send failed to 169.254.255.255(137) ERRNO=Invalid argument
[2017/04/25 20:22:35.887215,  0] ../source3/nmbd/nmbd_packets.c:179(send_netbios_packet)
  send_netbios_packet: send_packet() to IP 169.254.255.255 port 137 failed
[2017/04/25 20:22:35.887591,  0] ../source3/nmbd/nmbd_nameregister.c:582(register_name)
  register_name: Failed to send packet trying to register name __MSBROWSE__<01>
[2017/04/25 20:22:44.346724,  0] ../source3/nmbd/nmbd_become_lmb.c:397(become_local_master_stage2)
  *****

  Samba name server NASTER is now a local master browser for workgroup HOEVELAKEN on subnet 192.168.1.9

  *****
[2017/04/25 20:22:44.352689,  0] ../source3/nmbd/nmbd_browsesync.c:354(find_domain_master_name_query_fail)
  find_domain_master_name_query_fail:
  Unable to find the Domain Master Browser name HOEVELAKEN<1b> for the workgroup HOEVELAKEN.
  Unable to sync browse lists in this workgroup.
[2017/04/25 20:23:30.566467,  0] ../source3/libsmb/nmblib.c:873(send_udp)
  Packet send failed to 169.254.255.255(138) ERRNO=Invalid argument
[2017/04/25 20:23:32.091639,  0] ../source3/nmbd/nmbd.c:58(terminate)
  Got SIGTERM: going down...
[2017/04/25 20:23:32.119688,  0] ../source3/libsmb/nmblib.c:873(send_udp)
  Packet send failed to 127.0.0.1(137) ERRNO=Invalid argument
[2017/04/25 20:23:32.120172,  0] ../source3/nmbd/nmbd_packets.c:179(send_netbios_packet)
  send_netbios_packet: send_packet() to IP 127.0.0.1 port 137 failed
[2017/04/25 20:23:32.120556,  0] ../source3/nmbd/nmbd_namerelease.c:166(wins_release_name)
  release_name: Failed to send packet trying to release name HOEVELAKEN<1e> IP 169.254.100.100
[2017/04/25 20:23:32.121104,  0] ../source3/libsmb/nmblib.c:873(send_udp)
  Packet send failed to 127.0.0.1(137) ERRNO=Invalid argument
[2017/04/25 20:23:32.121519,  0] ../source3/nmbd/nmbd_packets.c:179(send_netbios_packet)
  send_netbios_packet: send_packet() to IP 127.0.0.1 port 137 failed
[2017/04/25 20:23:32.121881,  0] ../source3/nmbd/nmbd_namerelease.c:166(wins_release_name)
  release_name: Failed to send packet trying to release name HOEVELAKEN<00> IP 169.254.100.100
[2017/04/25 20:23:32.122343,  0] ../source3/libsmb/nmblib.c:873(send_udp)
  Packet send failed to 127.0.0.1(137) ERRNO=Invalid argument
[2017/04/25 20:23:32.122717,  0] ../source3/nmbd/nmbd_packets.c:179(send_netbios_packet)
  send_netbios_packet: send_packet() to IP 127.0.0.1 port 137 failed
[2017/04/25 20:23:32.123072,  0] ../source3/nmbd/nmbd_namerelease.c:166(wins_release_name)
  release_name: Failed to send packet trying to release name NASTER<00> IP 169.254.100.100
[2017/04/25 20:23:32.123522,  0] ../source3/libsmb/nmblib.c:873(send_udp)
  Packet send failed to 127.0.0.1(137) ERRNO=Invalid argument
[2017/04/25 20:23:32.123897,  0] ../source3/nmbd/nmbd_packets.c:179(send_netbios_packet)
  send_netbios_packet: send_packet() to IP 127.0.0.1 port 137 failed
[2017/04/25 20:23:32.124292,  0] ../source3/nmbd/nmbd_namerelease.c:166(wins_release_name)
  release_name: Failed to send packet trying to release name NASTER<03> IP 169.254.100.100
[2017/04/25 20:23:32.151689,  0] ../source3/libsmb/nmblib.c:873(send_udp)
  Packet send failed to 127.0.0.1(137) ERRNO=Invalid argument
[2017/04/25 20:23:32.152176,  0] ../source3/nmbd/nmbd_packets.c:179(send_netbios_packet)
  send_netbios_packet: send_packet() to IP 127.0.0.1 port 137 failed
[2017/04/25 20:23:32.152544,  0] ../source3/nmbd/nmbd_namerelease.c:166(wins_release_name)
  release_name: Failed to send packet trying to release name NASTER<20> IP 169.254.100.100
[2017/04/25 20:23:32.153065,  0] ../source3/libsmb/nmblib.c:873(send_udp)
  Packet send failed to 169.254.255.255(138) ERRNO=Invalid argument
[2017/04/25 20:23:33.124208,  0] ../lib/util/pidfile.c:146(pidfile_unlink)
  Failed to delete pidfile /var/lock/nmbd.pid. Error was No such file or directory
[2017/04/25 20:23:33.986290,  0] ../lib/util/become_daemon.c:124(daemon_ready)
  STATUS=daemon 'nmbd' finished starting up and ready to serve connections
[2017/04/25 20:23:56.512552,  0] ../source3/nmbd/nmbd_become_lmb.c:397(become_local_master_stage2)
  *****

  Samba name server NASTER is now a local master browser for workgroup HOEVELAKEN on subnet 192.168.1.9

  *****
[2017/04/25 20:23:56.686759,  0] ../source3/nmbd/nmbd_browsesync.c:354(find_domain_master_name_query_fail)
  find_domain_master_name_query_fail:
  Unable to find the Domain Master Browser name HOEVELAKEN<1b> for the workgroup HOEVELAKEN.
  Unable to sync browse lists in this workgroup.
[2017/04/25 20:29:50.660347,  0] ../source3/nmbd/nmbd.c:58(terminate)
  Got SIGTERM: going down...
[2017/04/25 20:29:51.233758,  0] ../lib/util/pidfile.c:146(pidfile_unlink)
  Failed to delete pidfile /var/lock/nmbd.pid. Error was No such file or directory
[2017/04/25 20:29:56.495792,  0] ../lib/util/become_daemon.c:124(daemon_ready)
  STATUS=daemon 'nmbd' finished starting up and ready to serve connections

What's that SIGTERM doing there? I didn't kill any processes myself, did it get caught in something? Linux OOM killer maybe?

[eggfish]

For others reading this thread, note that scsirob joined the discussion because of a similar problem to mine. The discussion with schumaku is therefore interleaved.

I have a similar log file too (and have the same problem again since rebooting: can't reach by name HAL):

[2017/04/26 07:02:22.797187, 0] ../lib/util/become_daemon.c:135(daemon_status)
STATUS=daemon 'nmbd' : No local IPv4 non-loopback interfaces available, waiting for interface ...NOTE: NetBIOS name resolution is not supported for Internet Protocol Version 6 (IPv6).
[2017/04/26 07:02:32.531223, 0] ../lib/util/become_daemon.c:124(daemon_ready)
STATUS=daemon 'nmbd' finished starting up and ready to serve connections
[2017/04/26 07:02:36.570876, 0] ../source3/libsmb/nmblib.c:873(send_udp)
Packet send failed to 169.254.255.255(137) ERRNO=Invalid argument
[2017/04/26 07:02:36.571449, 0] ../source3/nmbd/nmbd_packets.c:1638(retransmit_or_expire_response_records)
retransmit_or_expire_response_records: Failed to resend packet id 30813 to IP 169.254.255.255 on subnet 169.254.100.100
[2017/04/26 07:02:36.571863, 0] ../source3/libsmb/nmblib.c:873(send_udp)
Packet send failed to 169.254.255.255(137) ERRNO=Invalid argument
[2017/04/26 07:02:36.572237, 0] ../source3/nmbd/nmbd_packets.c:1638(retransmit_or_expire_response_records)
retransmit_or_expire_response_records: Failed to resend packet id 30814 to IP 169.254.255.255 on subnet 169.254.100.100
[2017/04/26 07:02:36.572652, 0] ../source3/libsmb/nmblib.c:873(send_udp)
Packet send failed to 169.254.255.255(137) ERRNO=Invalid argument
[2017/04/26 07:02:36.573024, 0] ../source3/nmbd/nmbd_packets.c:1638(retransmit_or_expire_response_records)
retransmit_or_expire_response_records: Failed to resend packet id 30815 to IP 169.254.255.255 on subnet 169.254.100.100
[2017/04/26 07:02:36.573402, 0] ../source3/libsmb/nmblib.c:873(send_udp)
Packet send failed to 169.254.255.255(137) ERRNO=Invalid argument
[2017/04/26 07:02:36.573770, 0] ../source3/nmbd/nmbd_packets.c:1638(retransmit_or_expire_response_records)
retransmit_or_expire_response_records: Failed to resend packet id 30816 to IP 169.254.255.255 on subnet 169.254.100.100
[2017/04/26 07:02:36.574146, 0] ../source3/libsmb/nmblib.c:873(send_udp)
Packet send failed to 169.254.255.255(137) ERRNO=Invalid argument
[2017/04/26 07:02:36.574529, 0] ../source3/nmbd/nmbd_packets.c:1638(retransmit_or_expire_response_records)
retransmit_or_expire_response_records: Failed to resend packet id 30817 to IP 169.254.255.255 on subnet 169.254.100.100
[2017/04/26 07:02:42.118562, 0] ../source3/nmbd/nmbd.c:58(terminate)
Got SIGTERM: going down...
[2017/04/26 07:02:42.119147, 0] ../source3/libsmb/nmblib.c:873(send_udp)
Packet send failed to 169.254.255.255(138) ERRNO=Invalid argument
[2017/04/26 07:02:42.157366, 0] ../lib/util/pidfile.c:146(pidfile_unlink)
Failed to delete pidfile /var/lock/nmbd.pid. Error was No such file or directory
[2017/04/26 07:02:43.229388, 0] ../lib/util/become_daemon.c:124(daemon_ready)
STATUS=daemon 'nmbd' finished starting up and ready to serve connections
[2017/04/26 07:02:46.560863, 0] ../lib/util/become_daemon.c:124(daemon_ready)
STATUS=daemon 'nmbd' finished starting up and ready to serve connections
[2017/04/26 07:03:06.801285, 0] ../source3/nmbd/nmbd_become_lmb.c:397(become_local_master_stage2)
*****

Samba name server HAL is now a local master browser for workgroup NAS on subnet 192.168.1.246

*****
[2017/04/26 07:03:08.832361, 0] ../source3/nmbd/nmbd_become_lmb.c:397(become_local_master_stage2)
*****

Samba name server HAL is now a local master browser for workgroup NAS on subnet 192.168.1.246

*****
[2017/04/26 07:03:35.476544, 0] ../source3/nmbd/nmbd.c:58(terminate)
Got SIGTERM: going down...
[2017/04/26 07:03:35.489611, 0] ../source3/nmbd/nmbd.c:58(terminate)
Got SIGTERM: going down...
[2017/04/26 07:03:35.781443, 0] ../lib/util/pidfile.c:146(pidfile_unlink)
Failed to delete pidfile /var/lock/nmbd.pid. Error was No such file or directory
[2017/04/26 07:03:35.812810, 0] ../lib/util/pidfile.c:146(pidfile_unlink)
Failed to delete pidfile /var/lock/nmbd.pid. Error was No such file or directory
[2017/04/26 07:03:36.147163, 0] ../lib/util/become_daemon.c:124(daemon_ready)
STATUS=daemon 'nmbd' finished starting up and ready to serve connections
[2017/04/26 07:03:59.751624, 0] ../source3/nmbd/nmbd_become_lmb.c:397(become_local_master_stage2)
*****

Samba name server HAL is now a local master browser for workgroup NAS on subnet 192.168.1.246

*****
[2017/04/26 07:04:51.251715, 0] ../source3/nmbd/nmbd.c:169(nmbd_sig_hup_handler)
Got SIGHUP dumping debug info.
[2017/04/26 07:04:51.262538, 0] ../source3/nmbd/nmbd_workgroupdb.c:276(dump_workgroups)
dump_workgroups()
dump workgroup on subnet 192.168.1.246: netmask= 255.255.255.0:
NAS(1) current master browser = HAL
HAL 40841a03 (NAS Server)
[2017/04/26 07:12:32.539868, 0] ../source3/nmbd/nmbd.c:58(terminate)
Got SIGTERM: going down...
[2017/04/26 07:12:34.122118, 0] ../lib/util/pidfile.c:146(pidfile_unlink)
Failed to delete pidfile /var/lock/nmbd.pid. Error was No such file or directory
[2017/04/26 07:12:36.738495, 0] ../lib/util/become_daemon.c:124(daemon_ready)
STATUS=daemon 'nmbd' finished starting up and ready to serve connections

Something is definitely up with nmbd, it's stopped and not running again:

[~] # ps waux | grep mbd
4555 admin 824 S /usr/local/samba/sbin/smbd -l /var/log -D -s /etc/config/smb.conf
4557 admin 412 S /usr/local/samba/sbin/smbd -l /var/log -D -s /etc/config/smb.conf
4558 admin 364 S /usr/local/samba/sbin/smbd -l /var/log -D -s /etc/config/smb.conf
4569 admin 520 S /usr/local/samba/sbin/smbd -l /var/log -D -s /etc/config/smb.conf
17955 admin 576 S grep mbd

Is the service failing to start because it can't find an interface to bind to? One other piece of info: I use power saving on my NAS, it sleeps between midnight and 7 - which is why you see the log trace above at about 2 minutes past 7, as it is coming out of sleep mode.

By the way I had a look at the smb config file and I could not see anything obvious, but I could post here if that would help?

Many thanks

[jfraser]

I just wanted to chime in here and say "Thanks!". I was having the same smb issues after upgrading to the 4.3.3 firmware, my smb shared folders were no longer accessible and I appreciate the help & troubleshooting that the eggfish & schumaku provided in this thread.

I followed the steps above:

[~] # smb2status
smbd (samba daemon) Version 4.4.9
smbd (samba daemon) is running.
max protocol SMB 1.0 enabled.

[~] # smb3enable
smbd (samba daemon) Version 4.4.9
smbd (samba daemon) is running.
max protocol SMB 3.0 enabled.

But that didn't seem to solve my problem, so I ran

Code: Select all

 testparm 

and discovered that there were a bunch of type-o's in my smb.conf file. I'm not sure if the firmware upgrade somehow created the problem in the smb.conf or if they were always in the file but had just been ignored but I went through and corrected them "nmo" should have been "no", "calid user" should have been "valid user"... etc. I then restarted smb with

Code: Select all

 ./smb.sh restart 

in /etc/init.d and all seems to be back to normal.

Now if I could just fix the GUI reporting that my CPU is pegged at 100% all the time....

[schumaku]

Welcome @jfrazer to the QNAP NAS Community Forum!

Is this all related to a TS-210 as shown in the forum profile? These can have had a long active life . Over the years, in early times we've seen some XML component blocks randomly in the smb.conf (or uLinux.conf), and even some kind of typos. Hard to say when these were "introduced". It's true, the previous SAMBA 3.6 parser was much more tolerant to typos and other mishaps then the decent SAMBA 4.4 we've got in place now.

When it comes to the CPU load, check what processes are involved. There are two kind of reports on 4.3.3 ref. CPU load on this tiny machines - some are related to active (re-)processing of data, ie. the Media Library, others state the CPU load on the QTS desktop (ie. in the Dashboard) is not properly updated under high load conditions, and seem to be stick up to 100%, same observation randomly here on my NAS, too.

We're glad to help.

Regards,
-Kurt

[Albert100]

Hi,

Same problem here: I can't access my shares since the last firmware update. I also discovered that long password are not supported when ssh-ing with Putty. Anyway, I successfully tried the smb3enable command, but it didn't work anymore after NAS reboot. I have to manually restart the smb service after each I reboot. How can this be fixed?