Hi all,

 

I recently had a hard drive that was on its last leg with 950 re-allocated sectors. I replaced it then I also upgraded to v6. Since then, user shares and SMB access seems to die after some time. When it dies, I am able to use the remote console and access the web UI, but I am unable to browse any of the user shares from windows or android devices until I restart the unraid system. I can access the disk shares at times without any issues, but with windows this is a pain because it spends minutes locking up explorer.exe trying to access the user shares before it gives up. From my searching it seems like my issue is very similar to this thread: http://lime-technology.com/forum/index.php?topic=48763.0

 

Based on that thread, it sounds like it may be my system and drives all being "reiserfs" perhaps with my hardware as a facator. Before I do roll back or decide to change them to XFS, I wanted to make sure I am on the right track and that I am not completely overlooking something. I am looking for advice and guidance from the people here who are much smarter than me!

 

I've attached is a diagnostics dump and my info on my Unraid system is below and I would greatly appreciate any support that could be provided! Thank you in advance!

 

 

Model: N/A

M/B: ASUSTeK COMPUTER INC. - P8H77-I

CPU: Intel® Pentium® CPU G860 @ 3.00GHz

HVM: Disabled

IOMMU: Disabled

Cache: 128 kB, 512 kB, 3072 kB

Memory: 4096 MB (max. installable capacity 16 GB)

Network: eth0: 1000Mb/s - Full Duplex

Kernel: Linux 4.1.18-unRAID x86_64

OpenSSL: 1.0.1s

Array: 5 Disk Array all 4 TB Seagate Drives (4 for data and 1 for parity)

 

P.S. a Memtest was run and passed without issues. All disks now pass the smart disk tests.

tower-diagnostics-20160507-1003.zip

Have you tried setting your server to become the Local Master?  ('Settings' >>> 'SMB' >>> 'Workgroup Settings') 

 

If you want to know which server on your network is your Local Master, install the "Local Master' plugin form the first post in this thread:

 

    http://lime-technology.com/forum/index.php?topic=36543.0

 

If you leave your server on 24-7, you really want your unRAID server to end up as the Local Master! 

 

BTW, the problem with the poster in the other thread was that all of his drives were almost completely filled up.  (If this happens for large HDD's, "reiserfs" can become very, very slow.)  Is this true with your server? 

Hi Frank, thanks for the reply. With my new drive I have 5 TB free, so I do not think that is a problem. Local Master was not enabled. I just enabled it. Thanks for the tip. I'll monitor and see if this has an impact.

I was able to set as local master browser and confirm that it was the local master after some time. It seems to have got marginally better but I still have many drops and terrible performance. Ican't use Plex, the scanning cuts out due to drops and half of my library is not found. Reading media files like photos is also painful with Adobe.

 

I'm at a lose where to go next with this. I've tried change cables and using an alternate gigabit network switch instead of my router with No success. I've also tried rolling back to v5 and still no success. I am leaning towards the integrated NIC, but nothing shows up in the Syslog to indicate that. Any thoughts out there? (I am currently on v6.1.9)

I was able to set as local master browser and confirm that it was the local master after some time. It seems to have got marginally better but I still have many drops and terrible performance. Ican't use Plex, the scanning cuts out due to drops and half of my library is not found. Reading media files like photos is also painful with Adobe.

 

I'm at a lose where to go next with this. I've tried change cables and using an alternate gigabit network switch instead of my router with No success. I've also tried rolling back to v5 and still no success. I am leaning towards the integrated NIC, but nothing shows up in the Syslog to indicate that. Any thoughts out there? (I am currently on v6.1.9)

 

I assume that you are using the onboard NIC.  What is the chip set that is used on the MB?  I can tell you that RealTek NIC have been problematic with version 6 of unRAID.  If you look at my component listing in my signature, you will see that I had to switch to an Intel Network Card to clear up stuttering while playing BluRay ISO's . 

 

I did look up your CPU and it has a PassMark rating of ~2800.  I understand that it takes a PassMark of 2000 for Plex to be able to transcode a single stream of video. 

 

One thing to try is to see what your speeds are to copy a single  LARGE file (~20GB) to and from the server.  That will give us a feel of whether the problem is the LAN connection or not. 

 

Also a list of all your plugins and dockers might reveal something. 

The on board NIC that I am using is a RealTek chipset (Motherboard: http://www.newegg.com/Product/Product.aspx?Item=N82E16813131841).

 

I am actually not running any extra dockers or plugins. I am using bare bones Unraid (webGuid and unRaidServer OS). I've been treating it like a dedicated NAS with no other function, therefore, I have Plex installed on another server and point to the Unraid only for the storage of it's media. This Unraid box was setup in 2013 and has been running smooth until I upgraded.

 

Per your instructions I attempted to transfer a 32.1 GB file and it failed almost as instantly as the calculation was over. I attached the diagnostics output in case it helps.

 

I guess all signs are pointing to the NIC. I am not even sure I can fit a PCI Express card in there. 

tower-diagnostics-20160511-0035.zip

Can someone tell us what is going on here?

 

 May  9 20:58:48 Tower kernel: r8169 0000:03:00.0 eth0: link down
May  9 20:58:50 Tower ntpd[1367]: Deleting interface #3 eth0, 192.168.223.12#123, interface stats: received=111, sent=640, dropped=0, active_time=74337 secs
May  9 20:58:50 Tower ntpd[1367]: 208.75.88.4 local addr 192.168.223.12 -> <null>
May  9 20:58:53 Tower kernel: r8169 0000:03:00.0 eth0: link up
May  9 20:58:54 Tower ntpd[1367]: Listen normally on 4 eth0 192.168.223.12:123
May  9 20:58:54 Tower ntpd[1367]: new interface(s) found: waking up resolver
May  9 21:38:19 Tower kernel: r8169 0000:03:00.0 eth0: link down
May  9 21:38:20 Tower ntpd[1367]: Deleting interface #4 eth0, 192.168.223.12#123, interface stats: received=11, sent=41, dropped=0, active_time=2366 secs
May  9 21:38:20 Tower ntpd[1367]: 208.75.88.4 local addr 192.168.223.12 -> <null>
May  9 21:38:23 Tower kernel: r8169 0000:03:00.0 eth0: link up
May  9 21:38:24 Tower ntpd[1367]: Listen normally on 5 eth0 192.168.223.12:123
May  9 21:38:24 Tower ntpd[1367]: new interface(s) found: waking up resolver
May  9 22:28:48 Tower kernel: mdcmd (71): spindown 0
May  9 22:37:43 Tower kernel: mdcmd (72): check CORRECT
May  9 22:37:43 Tower kernel: md: recovery thread woken up ...
May  9 22:37:43 Tower kernel: md: recovery thread checking parity...
May  9 22:37:43 Tower kernel: md: using 1536k window, over a total of 3907018532 blocks.
May  9 22:38:22 Tower sSMTP[7467]: Unable to locate smtp.gmail.com
May  9 22:38:22 Tower sSMTP[7467]: Cannot open smtp.gmail.com:465
May 10 07:46:10 Tower kernel: md: sync done. time=32907sec
May 10 07:46:10 Tower kernel: md: recovery thread sync completion status: 0
May 10 07:47:43 Tower sSMTP[20357]: Unable to locate smtp.gmail.com
May 10 07:47:43 Tower sSMTP[20357]: Cannot open smtp.gmail.com:465

 

Complete log in above post.

Can someone tell us what is going on here?

 

 May  9 20:58:48 Tower kernel: r8169 0000:03:00.0 eth0: link down
May  9 20:58:50 Tower ntpd[1367]: Deleting interface #3 eth0, 192.168.223.12#123, interface stats: received=111, sent=640, dropped=0, active_time=74337 secs
May  9 20:58:50 Tower ntpd[1367]: 208.75.88.4 local addr 192.168.223.12 -> <null>
May  9 20:58:53 Tower kernel: r8169 0000:03:00.0 eth0: link up
May  9 20:58:54 Tower ntpd[1367]: Listen normally on 4 eth0 192.168.223.12:123
May  9 20:58:54 Tower ntpd[1367]: new interface(s) found: waking up resolver
May  9 21:38:19 Tower kernel: r8169 0000:03:00.0 eth0: link down
May  9 21:38:20 Tower ntpd[1367]: Deleting interface #4 eth0, 192.168.223.12#123, interface stats: received=11, sent=41, dropped=0, active_time=2366 secs
May  9 21:38:20 Tower ntpd[1367]: 208.75.88.4 local addr 192.168.223.12 -> <null>
May  9 21:38:23 Tower kernel: r8169 0000:03:00.0 eth0: link up
May  9 21:38:24 Tower ntpd[1367]: Listen normally on 5 eth0 192.168.223.12:123
May  9 21:38:24 Tower ntpd[1367]: new interface(s) found: waking up resolver
May  9 22:28:48 Tower kernel: mdcmd (71): spindown 0
May  9 22:37:43 Tower kernel: mdcmd (72): check CORRECT
May  9 22:37:43 Tower kernel: md: recovery thread woken up ...
May  9 22:37:43 Tower kernel: md: recovery thread checking parity...
May  9 22:37:43 Tower kernel: md: using 1536k window, over a total of 3907018532 blocks.
May  9 22:38:22 Tower sSMTP[7467]: Unable to locate smtp.gmail.com
May  9 22:38:22 Tower sSMTP[7467]: Cannot open smtp.gmail.com:465
May 10 07:46:10 Tower kernel: md: sync done. time=32907sec
May 10 07:46:10 Tower kernel: md: recovery thread sync completion status: 0
May 10 07:47:43 Tower sSMTP[20357]: Unable to locate smtp.gmail.com
May 10 07:47:43 Tower sSMTP[20357]: Cannot open smtp.gmail.com:465

 

Complete log in above post.

 

That could of very well been when I switched out the wires and router to the new wires and switches. The time stamp matches up to about within the same hour that I did that.

I also found this:

 

May  9 00:03:28 Tower logger: /etc/rc.d/rc.inet1:  List of interfaces: 'eth0'
May  9 00:03:28 Tower logger: /etc/rc.d/rc.inet1:  /sbin/ifconfig lo 127.0.0.1
May  9 00:03:28 Tower logger: /etc/rc.d/rc.inet1:  /sbin/route add -net 127.0.0.0 netmask 255.0.0.0 lo
May  9 00:03:28 Tower logger: /etc/rc.d/rc.inet1:  /sbin/ifconfig eth0 192.168.223.12 broadcast 192.168.223.255 netmask 255.255.255.0
May  9 00:03:28 Tower kernel: r8169 0000:03:00.0 eth0: link down
May  9 00:03:28 Tower kernel: r8169 0000:03:00.0 eth0: link down
May  9 00:03:28 Tower logger: /etc/rc.d/rc.inet1:  /sbin/route add default gw 192.168.223.1 metric 1

 

I am wondering if you have set a static IP address for your server.  If you have, I would suggest changing it to something like 192.168.223.200 because that would take it out of the range that the DHCP process of your router would assign addresses to any other device that is requesting dynamic addresses as most routers start with 192.168.223.2 (in your case) and work its way up.  (I seriously doubt you have 190+ devices requesting addresses on your network.  Most home routers tend to throw in the towel when the number exceeds about 50.)

 

In any case, a static IP address is not a bad idea for unRAID servers.  Using a static address does free up the router for use by other devices. 

 

You might be surprised at the number of devices which can end up on your network and would be getting addresses using DHCP.  Right now, only my Granddaughter is over here and her IPad, IPhone and laptop are on the network.  If my wife decides to download a book to her Kindle, it grabs an  address.  When my whole family is here, I can visualize that there are fifteen to twenty additional devices that connect up at different times! 

I am wondering if you have set a static IP address for your server...

 

Yes, it's a static IP to which I've never had a problem with, but I do see your point. I'm thankful for the support and am happy to rule out more possible issues. Therefore, I've left the static at *.12 and changed the DHCP range to start with *.50 -> *.254. This should give me the same result. I'll report back if this changes anything.

I am wondering if you have set a static IP address for your server...

 

Yes, it's a static IP to which I've never had a problem with, but I do see your point. I'm thankful for the support and am happy to rule out more possible issues. Therefore, I've left the static at *.12 and changed the DHCP range to start with *.50 -> *.254. This should give me the same result. I'll report back if this changes anything.

 

I am not a real expert on routers but I think it will take quite some time before those devices are reassigned addresses in the new range.  My router's help table says this:

 

Address Lease Time - The Address Lease Time is the amount of time a network user will be allowed connection to the router with their 
current DHCP Address. Enter the amount of time, in minutes, that the user will be "leased" this DHCP Address. The range of the time is 
1~2880 minutes. The default value is 120 minutes.

 

I assume this allows a device to be off-line for up to 120 minutes (the default in this case) before the address is released for use by another device.  I doubt if the addresses are just randomly changed. Even, if it is off the LAN for a long period and no new device requests an address, it will be assigned the old address again.  I suspect you are going to have to reboot the router to get it to assign new addresses in the new range.  Note that you may have to reboot some of your other computers and devices if you do the router reboot. 

Hi Frank, I wanted to report back that after changing the DHCP Range and rebooting all my network devices. I am able to transfer a 30 GB file at 84 MB's per second without a drop out. All my Plex scanning issues seem to have gone away! I'll keep monitoring, but so far this might have been the cause and I would have never guessed it. I hope I am not putting the cart before the horse, but thank you again for all of your patients and help! I'll keep monitoring throughout the weekend!

Glad to hear that it is working (for now).  Static IP addresses with DHCP enabled have to be carefully thought out.  Some routers allow you to reserve addresses for devices with static IP addresses which can prevent problems.  Many of us have simply assigned the static address at (or very near) the top end of the range.  But there is simply no single solution which will work for everybody.  Because of that, folks will encounter problems occasionally.  I happened to catch yours because I didn't see a request for DHCP service from your server.  With the IP address of your server near the bottom end of the range, I though of the possibility that two devices might be trying to use the same IP address...

 

If it continues to work be sure to mark this thread as 'SOLVED'.