4.1.7 Slow To Respond To SMB Network Discovery...

[Quinten1]

You have to install the Enable Root SSH Access (http://www.readynas.com/?p=4203) plugin (if you haven't done this yet) and then log in using Putty or another terminal emulator. Once in, just type the command above.

[arsenicrun]

I see. I'm afraid that installing an addon, an ssh client, and diving into ssh access without being familiar with that stuff seems to be outside of my comfort zone. If there's more of a point and click way of finding out your info, I'd probably be more able to help.

As an update, I've downgraded my other 4.1.7 ReadyNAS Duo back to 4.1.6 and I am once again a happy user. My 3 Duo's are all socializing pleasantly and efficiently with all of their network friends.

[wiltonw]

Hi

I got the same problem with other users on this post. I wonder if Netgear will fix this problem sooner or later, or they basically forget the Sparc users with 4.1.7 and just let us use 4.1.6 from now on.

I am a Duo user, I use my Duo for my small business, I bought it on April of 2010, it is still under warranty. Same as most of the Sparc Readynas users, I looked forward to the official 4.1.7 update for a long time. However, after a lot of bugs fixed work. The latest official firmware still has seriously performance problem. Is it acceptable?

I am planning to get another NAS for my partner's office. We are considering to get a 4 bays high performance NAS this time, it will becoming our main central server, but I am hesitating to use Readynas series NAS now. If the Netgear personnel actually read this forum, please could you found out what happen and provide a solution as soon as possible.

Thanks a lot

[adam_p]

I had the same problem after going from 4.1.6 to 4.1.7.

I have the problem resolved as follows: I switched the Duo from DHCP to a fixed IP and the problem went away. I do not know why.

[WSJ]

O.k. let me summarize the issue for the NetGear technical support guys (hopefully they read the forum postings):

ReadyNAS (Duo) is inacceptably slow to respond SMB/SAMBA network share enumeration requests (it takes about 30s and more).
This refers to (single) file share access requests as well as to (status) requests to network printers (exposed by ReadyNAS).

- it effects everyone who is using RAIDiator 4.1.7 (those who purchased a brand-new model with 4.1.7 suffer the same)
- it can be temporarily fixed by toggling the CIFS service off and on (but that fix only lasts until the next reboot)
- downgrading to RAIDiator 4.1.6 resolves the problem (but is not acceptable for most customers)
- performing an OS reinstall does not help
- it effects also customers who have not installed the "Enable Root SSH Access" add-on
- using a fixed IP address seems to resolve the problem (so far only stated by one single customer)

After all those investigations performed by us customers, it's now NetGears turn to perform a proper root cause analysis (using their own equipment). I'm starting to get a bit disappointend of NetGear - actually I did hope that they are a bit more professional.

[wiltonw]

adam.p wrote:
I had the same problem after going from 4.1.6 to 4.1.7. I have the problem resolved as follows: I switched the Duo from DHCP to a fixed IP and the problem went away. I do not know why.

Thanks for your tip, but I am afraid that it is not working for my situation. Actually, I am using fixed IP for my Duo since the day one that I got it. I was happy with it until I upgraded to 4.1.7. 😞

[IanSav]

Hi WSJ,

Good summary. 🙂

Shame that Netgear is dragging its collective feet on this one. They are pushing ahead with betas for the 4.2.x series but even then they seem to move two steps forward then one step back. The 4.1.x series appears to be neglected in comparison. It is a shame that the sense of pride in quality of the firmware did not make the transition from Infrant to Netgear. (In the old days these sorts of reports were usually investigated and resolved within days. Even though the Jedi handles appear the same the response to customer requests and feedback is not. :()

Regards,
Ian.

[BikeHelmet]

Hello there,

Until recently I had a home-built Ubuntu NAS that exhibited the same symptoms. That was actually one of the reasons I was looking at NAS units. It also had the symptom of extremely slow folder creation - then after creating a "New Folder", I had to press F2 and rename it to something else.

I ultimately resolved it by changing the name resolve order in /etc/samba/smb.conf to include bcast.

It's unlikely that we have the same cause for the same symptoms, but it's something to look into.

[Berkhout]

WSJ wrote:

O.k. let me summarize the issue for the NetGear technical support guys (hopefully they read the forum postings): ReadyNAS (Duo) is inacceptably slow to respond SMB/SAMBA network share enumeration requests (it takes about 30s and more). This refers to (single) file share access requests as well as to (status) requests to network printers (exposed by ReadyNAS). - it effects everyone who is using RAIDiator 4.1.7 (those who purchased a brand-new model with 4.1.7 suffer the same) - it can be temporarily fixed by toggling the CIFS service off and on (but that fix only lasts until the next reboot) - downgrading to RAIDiator 4.1.6 resolves the problem (but is not acceptable for most customers) - performing an OS reinstall does not help - it effects also customers who have not installed the "Enable Root SSH Access" add-on - using a fixed IP address seems to resolve the problem (so far only stated by one single customer) After all those investigations performed by us customers, it's now NetGears turn to perform a proper root cause analysis (using their own equipment). I'm starting to get a bit disappointend of NetGear - actually I did hope that they are a bit more professional.

I totally agree with WSJ.

greetings Berkhout

[WSJ]

BikeHelmet wrote:
I ultimately resolved it by changing the name resolve order in /etc/samba/smb.conf to include bcast. It's unlikely that we have the same cause for the same symptoms, but it's something to look into.

Well - my ReadyNAS Duo (with 4.1.7 firmware) has

name resolve order = "lmhosts host wins bcast"

So, that seems not the cause.
PS: "smbd --version" returns "3.0.37" (with RAIDiator 4.1.7)

[WSJ]

http://samba.org/samba/history/samba-3.2.2.html:

"Fix freezing Windows Explorer on WinXP while browsing Samba shares.
This one led to timeouts during printing as well." (BUG #5617)

Well, that could be related (although it's not exactly the same issue).

[BikeHelmet]

Some more details:

1) The odd behaviour I experienced first occured after a Samba update.
2) Restarting Samba would cure it briefly. (perhaps 30-60 minutes)

WSJ wrote:
Well - my ReadyNAS Duo (with 4.1.7 firmware) has name resolve order = "lmhosts host wins bcast" So, that seems not the cause.

3) Previously my order was:

wins lmhosts host bcast

I changed it to this to resolve it:

wins bcast lmhosts host

Certain name resolve methods (WINS) were timing out for some reason. I assume there's an underlying bug/glitch in whatever version of Samba I had.

[WSJ]

Well, it would be interesting to know which Samba version is used in a ReadyNAS with RAIDiator 4.1.6.
And also the section "name resolve order" in /etc/samba/smb.conf should be compared with the one of RAIDiator 4.1.7.

Does anyone has a ReadyNAS with RAIDiator 4.1.6 and is willing to post his findings?

I assume that the Samba version is "3.0.34" (according to nmbd.log: I've noticed a change from "3.0.34" to "3.0.37" at the point in time when I've upgraded the firmware ...).

I've also noticed a change regarding the "Linux version" at the same time (according to system.log):
"2.6.17.8" -> "2.6.17.14"

And another change effects the "udhcp client":
"v0.9.8" -> "v1.14.3"

Can someone confirm / correct those assumptions?

[Milhouse]

I'm running 4.1.6 on an NV - I still don't think 4.1.7 is stable enough to warrant an upgrade, too many minor/niggling issues that need fixing or working around and taken collectively amount to a major issue/risk.

nas1:/# uname -a
Linux nas1 2.6.17.8ReadyNAS #1 Tue Jun 9 13:59:28 PDT 2009 padre unknown
nas1:/# smbd --version
Version 3.0.34

From the logs:

Jan 23 23:06:37 nas1 udhcpd: udhcp server (v0.9.8) started

[WSJ]

Thanks for the confirmation.

[IanSav]

Hi,

Are there any updates on this issue. More importantly, are there any fixes coming out soon?

Regards,
Ian.

[biggerbyte1]

I have this problem too. 4.1.7 was terrible for me, so I found 4.1.6 online from Netgear and reverted back to 4.1.6.. All is good again.

[WSJ]

Did anyone filed an official bug report at Netgear, already?
Although Netgear employees are reading the forum postings, this is not equivalent to an official bug report.
Has anyone obtained a case number?

[IanSav]

Hi WSJ,

WSJ wrote:
Did anyone filed an official bug report at Netgear, already? Although Netgear employees are reading the forum postings, this is not equivalent to an official bug report. Does anyone obtained a case number?

I haven't submitted an official bug report as Australian time zones don't map well with USA support times.

In the past such actions were unnecessary as staff here were quick to act and resolve bugs. It looks like Netgear no longer cares about its products. Overall the quality and timing of support has been declining for a while now. This is not like the good old days when Infrant never seemed to release a bad build to the public. If anything problematic ever did get out there was usually a patch within hours. It never took more than a few days for issues to be resolved. I remember when individual issues, like my problematic HP OfficeJet 9130, received individual attention on this forum with a patch being cut and made available for the very few others who also had issues with this multifunction printer. Contrast that with the current situation where there is a SMB problem affecting many, many users and we cant seem to get any traction for a fix.

If someone closer to the USA doesn't file a formal report and it appears that this is now required I will consider lodging one from Australia.

Regards,
Ian.

[WSJ]

"Your support request has been saved:
The reference number is 14577085, a representative will reply to you shortly."

I'll keep you in the loop.

PS: Linux users are facing the very same problems ... (and they propose to modify /etc/init.d/rc3 to restart samba after booting ReadyNAS)

[IanSav]

Hi WSJ,

Do you have any updates? Has opening a case with Netgear had any beneficial effect?

Regards,
Ian.

[WSJ]

IanSav wrote:
Do you have any updates? Has opening a case with Netgear had any beneficial effect?

So far: no. Initially the support guy seem not to have taken a deeper look onto the referenced forum posting, even.
Final statement: "I will consult with my colleagues and then contact you once I've updated information".
So, let's wait and see. :roll:

[WSJ]

I've just reproduced the issue, again.
In smbd.log I've found the following entries (created during the relevant time frame):

[2011/02/14 18:45:24, 0] lib/util_sock.c:get_peer_addr(1334)
  getpeername failed. Error was Transport endpoint is not connected
[2011/02/14 18:45:24, 0] lib/util_sock.c:get_peer_addr(1334)
  getpeername failed. Error was Transport endpoint is not connected
[2011/02/14 18:45:24, 0] lib/util_sock.c:write_data(562)
  write_data: write failure in writing to client 0.0.0.0. Error Connection reset by peer
[2011/02/14 18:45:24, 0] lib/util_sock.c:send_smb(871)
  Error writing 4 bytes to client. -1. (Connection reset by peer)
[2011/02/14 18:45:51, 2] auth/auth.c:check_ntlm_password(309)
  check_ntlm_password:  authentication for user [xxx] -> [xxx] -> [xxx] succeeded
[2011/02/14 18:46:24, 0] lib/util_sock.c:get_peer_addr(1334)
  getpeername failed. Error was Transport endpoint is not connected
[2011/02/14 18:46:24, 0] lib/util_sock.c:write_data(562)
  write_data: write failure in writing to client 192.168.2.115. Error Connection reset by peer
[2011/02/14 18:46:24, 0] lib/util_sock.c:send_smb(871)
  Error writing 4 bytes to client. -1. (Connection reset by peer)
[2011/02/14 18:46:50, 2] auth/auth.c:check_ntlm_password(309)
  check_ntlm_password:  authentication for user [xxx] -> [xxx] -> [xxx] succeeded
[2011/02/14 18:47:30, 0] smbd/server.c:main(942)
  smbd version 3.0.37 started.
  Copyright Andrew Tridgell and the Samba Team 1992-2009
[2011/02/14 18:47:47, 2] auth/auth.c:check_ntlm_password(309)
  check_ntlm_password:  authentication for user [xxx] -> [xxx] -> [xxx] succeeded

Remarkable: the "lib/util_sock.c" error entries.
18:45:24 - 18:46:50: 86 seconds waiting time. That's how long it took for the SMB network discovery.
([xxx] - I've replaced the actual username by 'xxx', '192.168.2.115' is the IP address of the PC requesting the share from the NAS)

At 18:47 I've stopped and restarted the CIFS service, see daemon.log (same in system.log):

Feb 14 18:47:08 NAS avahi-daemon[694]: Got SIGHUP, reloading.
Feb 14 18:47:08 NAS avahi-daemon[694]: Service group file /etc/avahi/services/cifs.service vanished, removing services.
Feb 14 18:47:09 NAS smbd[3061]: PAM pam_putenv: delete non-existent entry; KRB5CCNAME
Feb 14 18:47:31 NAS avahi-daemon[694]: Got SIGHUP, reloading.
Feb 14 18:47:31 NAS avahi-daemon[694]: Loading service file /etc/avahi/services/cifs.service.
Feb 14 18:47:32 NAS avahi-daemon[694]: Service "NAS (CIFS)" (/etc/avahi/services/cifs.service) successfully established.
Feb 14 18:47:59 NAS smbd[3189]: PAM pam_putenv: delete non-existent entry; KRB5CCNAME

After that, access to the shares worked - and in smbd.log there are no more "lib/util_sock.c" error entries.
("NAS" is the hostname of my ReadyNAS Duo)

network_settings.log does not show any network problems:

eth0      Link encap:Ethernet  HWaddr xx:xx:xx:xx:xx:xx  
          inet addr:192.168.2.100  Bcast:192.168.2.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:7936  Metric:1
          RX packets:4992 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2886 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:2049130 (1.9 MiB)  TX bytes:3491373 (3.3 MiB)
          Interrupt:41 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:38918 errors:0 dropped:0 overruns:0 frame:0
          TX packets:38918 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:2697778 (2.5 MiB)  TX bytes:2697778 (2.5 MiB)

JUMBO_FRAMES_eth0=1
SPEED_DUPLEX_eth0=AUTO_NEGOTIATION

[knefas]

I have a feeling this might be related to something more general than samba, as I have the same problem (very slow to mount) on nfs shares (also reported on http://www.readynas.com/forum/viewtopic.php?f=17&t=47624), and restarting the nfs daemon seems to fix it (at least temporarily).

[WSJ]

Good point - well, it seems that 4.1.7 has numberous bugs