Unable to access shared folders since firmware 4.3.3 update

[billmars]

TS219P+
Current firmware version: 4.3.3.0154

Having exactly the same problem. No longer able to access QNAP shares via Windows 10 machines.
Employing '/etc/init.d/smb.sh restart' brings connectivity back, but I suspect only until the next QNAP reboot.
My Android 'phone has no problem connecting.

[ToolmanJoe]

Of course, QNAP now says 4.25 is vulnerable to ransomware and we should upgrade to 4.33. So our options are risk a ransomware attack or use 4.33 that doesn't work. Hey, thanks QNAP! Maybe I'll buy a competitors product next time!

https://forums.theregister.co.uk/forum/ ... p_malware/

[ziki_]

I had same problem. Today I manually downloaded version 4.3.3.0174 build and it fully solved problem.

[OneCD]

Of course, QNAP now says 4.25 is vulnerable to ransomware and we should upgrade to 4.33. So our options are risk a ransomware attack or use 4.33 that doesn't work. Hey, thanks QNAP! Maybe I'll buy a competitors product next time!

This isn't ransomware. Let's blame them correctly, yeah?

[ToolmanJoe]

Sorry, had ransomware on the brain due to all the news today. I should have said malware. Nonetheless, I tried updating to 4.3.3.0174 and I still have the same problem. There has to be a service not starting because the same still applies. If I go into Microsoft Networking and change ANY setting then apply, the NAS comes to life until the next reboot. After reboot, I can't access any shares.

[Roby77]

@effetredici

yes it's a workaround ...waiting (I hope ) for new firmware

[schumaku]

Of course, QNAP now says 4.25 is vulnerable to ransomware and we should upgrade to 4.33.

No. QNAP says that under some conditions a vulnerable firmware installation claiming to be QTS 4.2.5 - but coming from a different source _and_ being compromised - can show up on a NAS unexpectedly. Leaving some newer discoveries (already addressed in QTS 4.3.3.0174) away, for now 4.2.5 can be used, just like on the NAS where 4.3.3 is not available. Much more urgent is to update to the current Photo Station -> Security Vulnerability Addressed in Photo Station 5.4.1 and 5.2.7.

[schumaku]

For those claiming their NAS SAMBA must be manually (re-)started following a boot ...

- does # smb2status show "smbd (samba daemon) is running." or "smbd (samba daemon) is not running."?

- And then, the information challenged some posts before would be interesting to see in the status before the manual restart -> viewtopic.php?f=185&t=131973#p612600

[Roby77]

For those claiming their NAS SAMBA must be manually (re-)started following a boot ...

- does # smb2status show "smbd (samba daemon) is running." or "smbd (samba daemon) is not running."?

- And then, the information challenged some posts before would be interesting to see in the status before the manual restart -> viewtopic.php?f=185&t=131973#p612600

hope i collected what you asked

smbd (samba daemon) Version 4.4.9
smbd (samba daemon) is running.
max protocol SMB 3.0 enabled.

[schumaku]

So is the problem that it's not possible to discover the NAS under it's name, access it in Explorer under it's name, or not even by \\[IP-address] ?

[stadt]

We also have a TS-131 (with SMB 3 enabled) and a TS-234A (with SMB 2.1 enabled) running 4.3.3.0174. there the problems continue and additionally I can't add any new NAS > NAS backup job.

Withe the latest 4.3.3.0188 (20170516) Nas > Nas backup works again. On the TS 131 I have only one zombie process, but on the TS-234A over 60 remain ... Seems I have to wait more updates before I give 4.3.3 a try on our TVS 671 again.

[cooper2012]

Just upgraded to 4.3.3.188 (released today), seems to have fixed it. Nothing in the LOG regarding SMB.

With 4.3.3.0154 I had several issues today after some reboots, smb3enable did not seem to help after rebooting the TS-412: I had to un- and re-assign drive letters to my shares.
@schumaku: \\NAS...8F\public... and also \192.168.2....\public... to reach my shares in the Explorer worked, though. Access to the GUI via IP-adress always worked.

[billmars]

TS219P+
Current firmware version: 4.3.3.0188

Just upgraded to above firmware. No longer able to access QNAP shares.
Invoking '/etc/init.d/smb.sh restart' brings connectivity back again.
QNAP missed the opportunity to remedy the problem with new firmware. Maybe they don't care.
Or is it just a handful of us unlucky people seeing this problem?

[megane72]

Hi to all, on my TS-412 after upgrading to 4.3.3 I'm currently in the situation that nmbd did not work correctly.

Currently updated to 4.3.3.0188

After each reboot this is my situation:

Code: Select all

[~] # smb2status

smbd (samba daemon) Version 4.4.9
smbd (samba daemon) is running.
max protocol SMB 3.0 enabled.

Code: Select all

[~] # ps -ef | grep mbd
 7029 admin       468 S   /usr/local/samba/sbin/smbd -l /var/log -D -s /etc/config/smb
 7033 admin       292 S   /usr/local/samba/sbin/smbd -l /var/log -D -s /etc/config/smb
 7034 admin       260 S   /usr/local/samba/sbin/smbd -l /var/log -D -s /etc/config/smb
 7172 admin       408 S   /usr/local/samba/sbin/smbd -l /var/log -D -s /etc/config/smb
31563 admin       576 S   grep mbd

Code: Select all

[~] # cat /var/log/log.nmbd
[2017/05/19 11:26:17.070036,  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/05/19 11:26:26.889521,  0] ../lib/util/become_daemon.c:124(daemon_ready)
  STATUS=daemon 'nmbd' finished starting up and ready to serve connections
[2017/05/19 11:26:37.993287,  0] ../source3/nmbd/nmbd.c:58(terminate)
  Got SIGTERM: going down...
[2017/05/19 11:26:38.061535,  0] ../lib/util/pidfile.c:146(pidfile_unlink)
  Failed to delete pidfile /var/lock/nmbd.pid. Error was No such file or directory
[2017/05/19 11:26:39.031029,  0] ../lib/util/become_daemon.c:124(daemon_ready)
  STATUS=daemon 'nmbd' finished starting up and ready to serve connections
[2017/05/19 11:26:42.272651,  0] ../source3/nmbd/nmbd.c:58(terminate)
  Got SIGTERM: going down...
[2017/05/19 11:26:42.998584,  0] ../lib/util/become_daemon.c:124(daemon_ready)
  STATUS=daemon 'nmbd' finished starting up and ready to serve connections
[2017/05/19 11:26:58.241291,  0] ../source3/libsmb/nmblib.c:873(send_udp)
  Packet send failed to 169.254.255.255(138) ERRNO=Invalid argument
[2017/05/19 11:27:00.332543,  0] ../source3/libsmb/nmblib.c:873(send_udp)
  Packet send failed to 169.254.255.255(138) ERRNO=Invalid argument
[2017/05/19 11:27:02.352485,  0] ../source3/libsmb/nmblib.c:873(send_udp)
  Packet send failed to 169.254.255.255(138) ERRNO=Invalid argument
[2017/05/19 11:27:04.374148,  0] ../source3/libsmb/nmblib.c:873(send_udp)
  Packet send failed to 169.254.255.255(138) ERRNO=Invalid argument
[2017/05/19 11:27:06.402534,  0] ../source3/libsmb/nmblib.c:873(send_udp)
  Packet send failed to 169.254.255.255(138) ERRNO=Invalid argument
[2017/05/19 11:27:06.430579,  0] ../source3/libsmb/nmblib.c:873(send_udp)
  Packet send failed to 169.254.255.255(137) ERRNO=Invalid argument
[2017/05/19 11:27:06.431068,  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/05/19 11:27:06.431490,  0] ../source3/nmbd/nmbd_nameregister.c:582(register_name)
  register_name: Failed to send packet trying to register name __MSBROWSE__<01>
[2017/05/19 11:27:14.543025,  0] ../source3/nmbd/nmbd_become_lmb.c:397(become_local_master_stage2)
  *****

  Samba name server WOPR-NAS is now a local master browser for workgroup WOPR-NET on subnet 192.168.2.199

  *****
[2017/05/19 11:27:56.646782,  0] ../source3/libsmb/nmblib.c:873(send_udp)
  Packet send failed to 169.254.255.255(138) ERRNO=Invalid argument
[2017/05/19 11:28:48.073968,  0] ../source3/nmbd/nmbd.c:58(terminate)
  Got SIGTERM: going down...
[2017/05/19 11:28:48.619942,  0] ../source3/libsmb/nmblib.c:873(send_udp)
  Packet send failed to 169.254.255.255(138) ERRNO=Invalid argument
[2017/05/19 11:28:49.490094,  0] ../lib/util/pidfile.c:146(pidfile_unlink)
  Failed to delete pidfile /var/lock/nmbd.pid. Error was No such file or directory
[2017/05/19 11:28:49.797851,  0] ../lib/util/become_daemon.c:124(daemon_ready)
  STATUS=daemon 'nmbd' finished starting up and ready to serve connections
[2017/05/19 11:29:11.182955,  0] ../source3/nmbd/nmbd_become_lmb.c:397(become_local_master_stage2)
  *****

  Samba name server WOPR-NAS is now a local master browser for workgroup WOPR-NET on subnet 192.168.2.199

  *****
[2017/05/19 11:34:58.257877,  0] ../source3/nmbd/nmbd.c:58(terminate)
  Got SIGTERM: going down...
[2017/05/19 11:34:59.308487,  0] ../lib/util/pidfile.c:146(pidfile_unlink)
  Failed to delete pidfile /var/lock/nmbd.pid. Error was No such file or directory
[2017/05/19 11:35:03.982523,  0] ../lib/util/become_daemon.c:124(daemon_ready)
  STATUS=daemon 'nmbd' finished starting up and ready to serve connections

So nmbd will not stay up and the QNAP did not reply to the name but only to the IP

I can solve on each reboot by running

Code: Select all

/etc/init.d/smb.sh restart

But I hope to fix it definetively in some way....any suggestion?

Don't know if the setting "Local master browser" under ControlPanel->Win/Mac/NFS->MicrosoftNetworking->AdvancedOptions
will help, now is checked.

Or if I have to wait undefinitely for an upgrade that will fix this.

[staki]

Exactly the same problem here.
After upgrading to 4.3.3 I am unable to access to shared folders...
Even after upgrading to 4.3.3.0174 and 4.3.3.0188 I have always the same problem.
My system is Linux Opensuse leap 42.1, but I guess I would have the same problem with any version of Windows.

Will QNAP staff do something or just leave people being stuck with an unusable NAS ?