Unable to access shared folders since firmware 4.3.3 update

[megane72]

Ok to be fair is not really unusable, if it is my same situation, a simple restart of the smb after each reboot will fix until next reboot, normally I have the NAS up&run H24 so no big problem.....until on these days QNAP sort out with a daily update so I have to do a daily reboot.....

[megane72]

Ok, seems that I resolved unchecking the "Local master browser" option, according to QNAP HELP:

Local Domain Master: A Domain Master Browser is responsible for collecting and recording resources and services available for each PC on the network or a workgroup of Windows. When you find the waiting time for loading network resources to be too long, it may be caused by a failure of an existing master browser or a missing master browser on the network. If there is no master browser on your network, select the option "Domain Master" to configure the NAS as the master browser. Do not enable this option if you are unsure about the settings.

Probably now the translation from IP to NAME is demanded to my router (I say correctly) and works.

Don't ask me how and when this option got enabled...

[PatrickPR]

Found this topic with Google, when I started searching for a solution for the exact same problems as described in this topic. I have a TS-419P+ which I updated to 4.3.3, and after that the problems occured. I couldn't find my NAS in a Windows Explorer. I quickly found out that is was the SMB server, which needed a restart after each boot to become visible in the network (and have to do that every day because I use the power scheme and have the NAS shut down every evening).

I opened a ticket wich QNAP support, but until now none of the solutions worked. I had the NAS put back to a basic reset and restored the default smb config, both of the solutions didn't solve the problem. QNAP support has put my ticket to the technical engineers for deeper analysis. I updated to 4.3.3.0174 and 4.3.3.0188 and for some reason the last couple of days the NAS seems to work as normal for the network share part. But I also discovered that several remote backup options are also not working, such as NAS to NAS backup, RTRR and Rsync remote replication, it's just not possible to add a new rsync task due to some configuration error in the destination or port or credentials. I'm pretty sure is has something to do with the QNAP because I ruled out the rsync-server through several tests.

And to add more, I just discovered that it is also not possible to add a network connection in File Station. Again some error that de destination or credentials are incorrect. I'm sure it is all related to the messed up SMB service due to the firmware update. Just wanted to vent my story, I'll keep reading here for a possible solution.

[billmars]

This is getting worse.
Cannot access QNAP shares, even when invoking '/etc/init.d/smb.sh restart'.

The response from ' smb2status show ' gives:-
smbd (samba daemon) Version 4.4.9
smbd (samba daemon) is running.
max protocol SMB 3.0 enabled.

I'll try a reboot.

[billmars]

A quick follow up.
I was going to reboot the QNAP, but on a whim rebooted the PC.
Trying to access QNAP shares now gave a request to login to the server (something that doesn't happen normally).
When logged on, shares are now available.
So it looks as though the PC had lost the (in the past) remembered login.
Perhaps the PC is not requesting login details and therefore not able to access the QNAP. A situation I have encountered in the past.

[ToolmanJoe]

Running "/etc/init.d/smb.sh restart" works for me too. So what is happening here? Samba is running but is not initializing properly? -Joe

[scsirob]

The problem appears to be with nmbd, the NetBIOS Message Block server module. It still happens with the latest firmware on my TS412. I upgraded this morning hoping this was fixed but it isn't. The nmbd daemon starts normal. When logged in to a shell you can run "# ps -ef | grep mbd" and you will find an instance of nmbd running alongside a few smbd instances.

Code: Select all

[/var/log] # ps -ef | grep mbd
 2450 admin           Z   [nmbd]
 2814 admin           Z   [nmbd]
 3217 admin           Z   [nmbd]
 4768 admin           Z   [smbd]
 5157 admin      1104 S   /usr/local/samba/sbin/smbd -l /var/log -D -s /etc/config/smb.conf
 5161 admin       972 S   /usr/local/samba/sbin/smbd -l /var/log -D -s /etc/config/smb.conf
 5162 admin       976 S   /usr/local/samba/sbin/smbd -l /var/log -D -s /etc/config/smb.conf
 5176 admin      1104 S   /usr/local/samba/sbin/smbd -l /var/log -D -s /etc/config/smb.conf
 5225 admin      1328 S   /usr/local/samba/sbin/nmbd -l /var/log -D -s /etc/config/smb.conf
 9795 admin       568 S   grep mbd

The nmbd daemon is present (process ID 5225), and the log.nmbd file shows:

Code: Select all

[2017/05/21 14:34:54.977215,  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/05/21 14:34:54.977738,  0] ../source3/libsmb/nmblib.c:873(send_udp)
  Packet send failed to 169.254.255.255(138) ERRNO=Invalid argument
[2017/05/21 14:34:55.871571,  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/21 14:34:56.289710,  0] ../lib/util/become_daemon.c:124(daemon_ready)
  STATUS=daemon 'nmbd' finished starting up and ready to serve connections
[2017/05/21 14:35:18.740462,  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/05/21 14:35:18.781029,  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.

Then, after a while, the nmbd process disappears. When looking at /var/log/log.nmbd I can actually see that the process was terminated by some external influence, about 5 minutes after system boot. That 5 minutes is pretty consistent across multiple boots. Here's the output:

Code: Select all

[2017/05/21 14:34:54.977215,  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/05/21 14:34:54.977738,  0] ../source3/libsmb/nmblib.c:873(send_udp)
  Packet send failed to 169.254.255.255(138) ERRNO=Invalid argument
[2017/05/21 14:34:55.871571,  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/21 14:34:56.289710,  0] ../lib/util/become_daemon.c:124(daemon_ready)
  STATUS=daemon 'nmbd' finished starting up and ready to serve connections
[2017/05/21 14:35:18.740462,  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/05/21 14:35:18.781029,  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/05/21 14:40:05.627172,  0] ../source3/nmbd/nmbd.c:58(terminate)
  Got SIGTERM: going down...
[2017/05/21 14:40:07.726798,  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/21 14:40:12.099947,  0] ../lib/util/become_daemon.c:124(daemon_ready)
  STATUS=daemon 'nmbd' finished starting up and ready to serve connections

Note the Got SIGTERM: going down... line at the bottom.

Code: Select all

[/var/log] # ps -ef | grep mbd
 5157 admin       312 S   /usr/local/samba/sbin/smbd -l /var/log -D -s /etc/config/smb.conf
 5161 admin       320 S   /usr/local/samba/sbin/smbd -l /var/log -D -s /etc/config/smb.conf
 5162 admin       308 S   /usr/local/samba/sbin/smbd -l /var/log -D -s /etc/config/smb.conf
 5176 admin       408 S   /usr/local/samba/sbin/smbd -l /var/log -D -s /etc/config/smb.conf
13023 admin       576 S   grep mbd

The nmbd process is forced to terminate. But by what??

Interesting observation: If you run "/etc/init.d/smb.sh restart" manually after nmbd terminated, the process keeps running just fine. It looks like something in the boot sequence is causing this problem.
In the early boot stages something seems to start smb.sh as well (see the 'Z' processes above). Could this contribute to the problem? Something cleaning up these processes and hitting the active nmbd by mistake?

[Roby77]

another (temp solution waiting for a firmware update ) is to edit hosts file in windows

IP nas_name

[PatrickPR]

The problem appears to be with nmbd, the NetBIOS Message Block server module. It still happens with the latest firmware on my TS412. I upgraded this morning hoping this was fixed but it isn't. The nmbd daemon starts normal. When logged in to a shell you can run "# ps -ef | grep mbd" and you will find an instance of nmbd running alongside a few smbd instances.

Code: Select all

[/var/log] # ps -ef | grep mbd
 2450 admin           Z   [nmbd]
 2814 admin           Z   [nmbd]
 3217 admin           Z   [nmbd]
 4768 admin           Z   [smbd]
 5157 admin      1104 S   /usr/local/samba/sbin/smbd -l /var/log -D -s /etc/config/smb.conf
 5161 admin       972 S   /usr/local/samba/sbin/smbd -l /var/log -D -s /etc/config/smb.conf
 5162 admin       976 S   /usr/local/samba/sbin/smbd -l /var/log -D -s /etc/config/smb.conf
 5176 admin      1104 S   /usr/local/samba/sbin/smbd -l /var/log -D -s /etc/config/smb.conf
 5225 admin      1328 S   /usr/local/samba/sbin/nmbd -l /var/log -D -s /etc/config/smb.conf
 9795 admin       568 S   grep mbd

The nmbd daemon is present (process ID 5225), and the log.nmbd file shows:

Code: Select all

[2017/05/21 14:34:54.977215,  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/05/21 14:34:54.977738,  0] ../source3/libsmb/nmblib.c:873(send_udp)
  Packet send failed to 169.254.255.255(138) ERRNO=Invalid argument
[2017/05/21 14:34:55.871571,  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/21 14:34:56.289710,  0] ../lib/util/become_daemon.c:124(daemon_ready)
  STATUS=daemon 'nmbd' finished starting up and ready to serve connections
[2017/05/21 14:35:18.740462,  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/05/21 14:35:18.781029,  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.

Then, after a while, the nmbd process disappears. When looking at /var/log/log.nmbd I can actually see that the process was terminated by some external influence, about 5 minutes after system boot. That 5 minutes is pretty consistent across multiple boots. Here's the output:

Code: Select all

[2017/05/21 14:34:54.977215,  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/05/21 14:34:54.977738,  0] ../source3/libsmb/nmblib.c:873(send_udp)
  Packet send failed to 169.254.255.255(138) ERRNO=Invalid argument
[2017/05/21 14:34:55.871571,  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/21 14:34:56.289710,  0] ../lib/util/become_daemon.c:124(daemon_ready)
  STATUS=daemon 'nmbd' finished starting up and ready to serve connections
[2017/05/21 14:35:18.740462,  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/05/21 14:35:18.781029,  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/05/21 14:40:05.627172,  0] ../source3/nmbd/nmbd.c:58(terminate)
  Got SIGTERM: going down...
[2017/05/21 14:40:07.726798,  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/21 14:40:12.099947,  0] ../lib/util/become_daemon.c:124(daemon_ready)
  STATUS=daemon 'nmbd' finished starting up and ready to serve connections

Note the Got SIGTERM: going down... line at the bottom.

Code: Select all

[/var/log] # ps -ef | grep mbd
 5157 admin       312 S   /usr/local/samba/sbin/smbd -l /var/log -D -s /etc/config/smb.conf
 5161 admin       320 S   /usr/local/samba/sbin/smbd -l /var/log -D -s /etc/config/smb.conf
 5162 admin       308 S   /usr/local/samba/sbin/smbd -l /var/log -D -s /etc/config/smb.conf
 5176 admin       408 S   /usr/local/samba/sbin/smbd -l /var/log -D -s /etc/config/smb.conf
13023 admin       576 S   grep mbd

The nmbd process is forced to terminate. But by what??

Interesting observation: If you run "/etc/init.d/smb.sh restart" manually after nmbd terminated, the process keeps running just fine. It looks like something in the boot sequence is causing this problem.
In the early boot stages something seems to start smb.sh as well (see the 'Z' processes above). Could this contribute to the problem? Something cleaning up these processes and hitting the active nmbd by mistake?

This looks as very usefull information for QNAP support to me. Did you share your observation with them? I have a ticket open at QNAP support about this issue, and pointed them (more or less) in the direction of the boot sequence where it goes wrong.

[scsirob]

I don't have a ticket open with them. Feel free to share this with QNAP support if it helps resolve the issue.

While digging into this, one thing I noticed was that the smb service is being started quite early in the boot sequence. When you look at the /etc/rcS.d directory you can see that S62smb starts the services. Other protocols like iSCSI, AppleTalk and NFS are started way later in the boot sequence. I compared this with a CentOS Linux install and there the smb services start way later also.

For test I tried renaming S62smb to S97smb to make the service start later in the boot sequence, but it appears the QNAP boot system actually copies the /etc/rcS.d directory from some other place. I did see that there are a few intermediate mount/unmount steps in the boot that may provide access to the config scripts, but I have not figured out the details on it yet, and I'd rather not brick the NAS by futzing too much with it.

[megane72]

Since the problem seems related to nmbd, have you tried to disable the option "Local master browser" in QNAP configuration?

I think it is that that starts and use the nmbd.

Seems that solved my problem very similar if not equal to yours.

In my opinion the nmdb and "Local master browser" are not needed since you can defer (in my opninion correctly) the name/ip translation to the router of your intranet.

For me is not correct that this translation should be performed by the NAS.

[gusa6666]

Same problem here.
SMB 3.0 was already active. Restarting smb.sh does not help here.
Local Master Browser was never aktive.

Firmware: 4.3.3.0188
TVS-1282

[scsirob]

Since the problem seems related to nmbd, have you tried to disable the option "Local master browser" in QNAP configuration?

I think it is that that starts and use the nmbd.

Seems that solved my problem very similar if not equal to yours.

In my opinion the nmdb and "Local master browser" are not needed since you can defer (in my opninion correctly) the name/ip translation to the router of your intranet.

For me is not correct that this translation should be performed by the NAS.

I'm unsure why you think the router should be involved in this. The router runs a bind DNS service which deals with IP name resolution (forwarding and local LAN) but it doesn't speak CIFS/SMB.

As an always-on device, I would think the QNAP is the perfect candidate to be local master browser. Even if disabling local master browser on the QNAP fixes(?) the problem, why has it always worked for the past years, and what is different now to justify that I'd have to change settings?

[megane72]

The problem, at least in my case, is the translation of the name.
If I connect to the NAS with IP I have no problem (CIFS/SMB whatever you need), the problem are for all the connection that before 4.3.3 are setted up with NAS name and after 4.3.3 di not work anymore.
I did not want to change all those connection from name to IP.
For sure the problem is related to the name ip translation and only for the NAS.
Probably I have always had the local master browser activated on the NAS not knowing it was.
The default setting for the NAS is with LMB off, not on, don't know in my case when it went up in my history.
I suppose that some malfunction on nmdb on the newer firmware of QNAP or a different way to manage name/ip translation by it may go in conflict with the router that do the same service and is always on, at least in my network, but I cannot figure a network without a router today.

So in my case, disabling the LMB (that by default should be off) works.

Is up to you to try the same fix/workaround.

I'm not a network guru, I just explained what has worked for me.

[PatrickPR]

I agree with scsirob, I think the problem is in de boot sequence of a couple of processes. In my case, the LMB is off, and has always been off. The issue always appears after a colt boot (with power button) or scheduled boot, and never after a reboot from QTS.

Also, I find it strange that besides the shares that are not accessible, some other things are also not working. All of them have something to do with translating IP's and names to other network devices. In my case, I can't add Rsync tasks in Backup Manager and external network connections in File Manager, both because the NAS can't connect to the other end. I'm hoping that whatever solution QNAP support comes up with, it will also solve these secondary issues that I believe are related to the same problem.