After updating to v6.2.4 one of my Windows 10 Pro fails to access unRAID


wyee

Recommended Posts

Hello, I am experiencing a strange problem just recently. I had allowed my unRAID server to auto-update to the latest unRAID releases this past week. After that I started experiencing problems with one of my Windows 10 Pro PC's where it can no longer access unRAID shares nor can it even get to the web GUI. It is behaving oddly where before it was having no problems all. The windows 10 pc did get a cumulative security update on 11/08/2016 which I have uninstalled and hidden using a Microsoft utility that Miocrosoft provides. The Windows 10 Pro 64bit PC is not updated to the latest Windows 10 Anniversary edition. It is still at Windows 10 version 1151.

 

Here are the symptoms:

1) Using File Explorer the unRAID server shows up under networks along with my several other NAS servers.

I click on the unRAID servername and it shows all the drive shares as normal. But when I click on any of the shares to access its contents, that's where it sits there with the green progress bar slowly moving along at the top of the screen.  It never recovers at this point.

 

2) Using any web browser (IE11, Chrome or Firefox), I enter the http://<ipaddress> of the unRAID server to login to the web GUI.  It displays the login window where I enter credentials as I do normally and hit enter.  After that, it hangs with the progress bar or indicator spinning forever.

 

It never accesses the unRAID server.  I have to kill all the proicesses to exit out of the explorers.

 

3) I have tried removing the old Windows logon CREDENTIALS from the Windows 10 PC and relogging in new.  Still same hang. Still cannot get access connection.

Yes, my workgroup names all match up on all my servers so it's not that. Remember this PC was accessing the unRAID fine just a few days ago before any updates.

 

4) Most noteful is that all my other PC's and android devices can still login and access this same unRAID server just fine as normal.  It is just this one Windows 10 PC that something changed between it and unRAID protocol that has broken it.  I am trying to find out what it might be.  It is pointing to something on this particular Windows 10 PC since all my other Windows 10 PC's can still connect and access the updated unRAID server.

 

 

When I kill the hung process of the Web Browser session on the Windows 10 PC, I see the following syslog messages logged in unRAID:

 

Nov  9 10:52:38 SERVER01 emhttp: err: sendFile: sendfile /usr/local/emhttp/webGui/styles/default-fonts.css: Broken pipe

Nov  9 10:52:38 SERVER01 emhttp: err: need_authorization: getpeername: Transport endpoint is not connected

Nov  9 10:52:38 SERVER01 emhttp: err: sendFile: sendfile /usr/local/emhttp/webGui/styles/jquery.sweetalert.css: Broken pipe

Nov  9 10:52:38 SERVER01 emhttp: err: need_authorization: getpeername: Transport endpoint is not connected

Nov  9 10:52:38 SERVER01 emhttp: err: sendFile: sendfile /usr/local/emhttp/webGui/styles/default-white.css: Broken pipe

Nov  9 10:52:38 SERVER01 emhttp: err: need_authorization: getpeername: Transport endpoint is not connected

Nov  9 10:52:38 SERVER01 emhttp: err: sendFile: sendfile /usr/local/emhttp/webGui/styles/dynamix-white.css: Broken pipe

Nov  9 10:52:38 SERVER01 emhttp: err: need_authorization: getpeername: Transport endpoint is not connected

Nov  9 10:52:38 SERVER01 emhttp: err: sendFile: sendfile /usr/local/emhttp/webGui/javascript/dynamix.js: Broken pipe

Nov  9 10:59:26 SERVER01 emhttp: err: need_authorization: getpeername: Transport endpoint is not connected

Nov  9 10:59:26 SERVER01 emhttp: err: sendFile: sendfile /usr/local/emhttp/webGui/styles/default-fonts.css: Broken pipe

Nov  9 10:59:26 SERVER01 emhttp: err: need_authorization: getpeername: Transport endpoint is not connected

Nov  9 10:59:26 SERVER01 emhttp: err: sendFile: sendfile /usr/local/emhttp/webGui/styles/dynamix-white.css: Broken pipe

Nov  9 10:59:26 SERVER01 emhttp: err: need_authorization: getpeername: Transport endpoint is not connected

Nov  9 10:59:26 SERVER01 emhttp: err: sendFile: sendfile /usr/local/emhttp/webGui/styles/jquery.sweetalert.css: Broken pipe

Nov  9 10:59:26 SERVER01 emhttp: err: need_authorization: getpeername: Transport endpoint is not connected

Nov  9 10:59:26 SERVER01 emhttp: err: sendFile: sendfile /usr/local/emhttp/webGui/styles/font-awesome.css: Broken pipe

Nov  9 10:59:26 SERVER01 emhttp: err: need_authorization: getpeername: Transport endpoint is not connected

Nov  9 10:59:26 SERVER01 emhttp: err: sendFile: sendfile /usr/local/emhttp/webGui/styles/default-white.css: Broken pipe

Nov  9 10:59:26 SERVER01 emhttp: err: need_authorization: getpeername: Transport endpoint is not connected

Nov  9 10:59:26 SERVER01 emhttp: err: sendFile: sendfile /usr/local/emhttp/webGui/javascript/dynamix.js: Broken pipe

Nov  9 11:00:44 SERVER01 emhttp: err: sendFile: sendfile /usr/local/emhttp/webGui/styles/default-fonts.css: Broken pipe

Nov  9 11:00:44 SERVER01 emhttp: err: need_authorization: getpeername: Transport endpoint is not connected

Nov  9 11:00:45 SERVER01 emhttp: err: sendFile: sendfile /usr/local/emhttp/webGui/styles/font-awesome.css: Broken pipe

Nov  9 11:00:45 SERVER01 emhttp: err: need_authorization: getpeername: Transport endpoint is not connected

Nov  9 11:00:45 SERVER01 emhttp: err: sendFile: sendfile /usr/local/emhttp/webGui/styles/jquery.sweetalert.css: Broken pipe

Nov  9 11:00:45 SERVER01 emhttp: err: need_authorization: getpeername: Transport endpoint is not connected

Nov  9 11:00:45 SERVER01 emhttp: err: sendFile: sendfile /usr/local/emhttp/webGui/styles/default-white.css: Broken pipe

Nov  9 11:00:45 SERVER01 emhttp: err: need_authorization: getpeername: Transport endpoint is not connected

Nov  9 11:00:45 SERVER01 emhttp: err: sendFile: sendfile /usr/local/emhttp/webGui/styles/dynamix-white.css: Broken pipe

Nov  9 11:00:45 SERVER01 emhttp: err: need_authorization: getpeername: Transport endpoint is not connected

Nov  9 11:00:45 SERVER01 emhttp: err: sendFile: sendfile /usr/local/emhttp/webGui/javascript/dynamix.js: Broken pipe

Nov  9 11:00:54 SERVER01 emhttp: err: need_authorization: getpeername: Transport endpoint is not connected

Nov  9 11:00:54 SERVER01 emhttp: err: sendFile: sendfile /usr/local/emhttp/webGui/styles/default-fonts.css: Broken pipe

Nov  9 11:10:07 SERVER01 emhttp: err: need_authorization: getpeername: Transport endpoint is not connected

Nov  9 11:10:07 SERVER01 emhttp: err: sendFile: sendfile /usr/local/emhttp/webGui/styles/jquery.sweetalert.css: Broken pipe

Nov  9 11:10:07 SERVER01 emhttp: err: need_authorization: getpeername: Transport endpoint is not connected

Nov  9 11:10:07 SERVER01 emhttp: err: sendFile: sendfile /usr/local/emhttp/webGui/styles/default-white.css: Broken pipe

Nov  9 11:10:07 SERVER01 emhttp: err: need_authorization: getpeername: Transport endpoint is not connected

Nov  9 11:10:07 SERVER01 emhttp: err: sendFile: sendfile /usr/local/emhttp/webGui/styles/dynamix-white.css: Broken pipe

Nov  9 11:10:07 SERVER01 emhttp: err: need_authorization: getpeername: Transport endpoint is not connected

Nov  9 11:10:07 SERVER01 emhttp: err: sendFile: sendfile /usr/local/emhttp/webGui/javascript/dynamix.js: Broken pipe

Nov  9 11:24:54 SERVER01 kernel: mdcmd (42): spindown 2

Nov  9 11:26:34 SERVER01 emhttp: err: need_authorization: getpeername: Transport endpoint is not connected

Nov  9 11:26:34 SERVER01 emhttp: err: sendFile: sendfile /usr/local/emhttp/webGui/styles/font-awesome.css: Broken pipe

Nov  9 11:26:34 SERVER01 emhttp: err: need_authorization: getpeername: Transport endpoint is not connected

Nov  9 11:26:34 SERVER01 emhttp: err: sendFile: sendfile /usr/local/emhttp/webGui/styles/jquery.sweetalert.css: Broken pipe

Nov  9 11:26:34 SERVER01 emhttp: err: need_authorization: getpeername: Transport endpoint is not connected

Nov  9 11:26:34 SERVER01 emhttp: err: sendFile: sendfile /usr/local/emhttp/webGui/styles/default-white.css: Broken pipe

Nov  9 11:26:34 SERVER01 emhttp: err: need_authorization: getpeername: Transport endpoint is not connected

Nov  9 11:26:34 SERVER01 emhttp: err: sendFile: sendfile /usr/local/emhttp/webGui/javascript/dynamix.js: Broken pipe

Nov  9 11:26:34 SERVER01 emhttp: err: need_authorization: getpeername: Transport endpoint is not connected

Nov  9 11:26:34 SERVER01 emhttp: err: sendFile: sendfile /usr/local/emhttp/webGui/styles/dynamix-white.css: Broken pipe

Nov  9 12:43:33 SERVER01 kernel: mdcmd (43): spindown 2

Nov  9 12:43:37 SERVER01 emhttp: err: need_authorization: getpeername: Transport endpoint is not connected

Nov  9 12:44:02 SERVER01 emhttp: err: need_authorization: getpeername: Transport endpoint is not connected

Nov  9 12:44:06 SERVER01 emhttp: err: need_authorization: getpeername: Transport endpoint is not connected

 

I see the mention in the log entries about need authorization... so what in Windows or unRAID changed to cause that? and what is the fix?

Link to comment

For those thinking that this does not apply to a possible unRAID bug... I should mention that on the problematic Windows 10 Pro PC that fails to connect and access the unRAID server, the PC can access all my other NAS server devices.  The other NAS servers I can connect successfully to are WD MyCloud, ReadyNAS Duo, ReadyNAS NV+ and a FreeNAS server.  The only one refusing to cooperate with this Windows 10 Pro PC is the recently updated v6.2.4 unRAID server.  Something must have changed in the unRAID update that is causing the failure to connect.  I am thinking it is credentials or some sort of certificate authentication related that might have changed and become incompatible between the new unRAID update and the new Windows 10 updates.  Anyone have any ideas what might have caused this?

Link to comment

Nevermind, I found the problem and fixed it. I suspected that something might have gone wrong with my Ethernet LAN driver settings that made it not work with unRAID connections.  So I plugged in a Wi-Fi USB dongle adapter I had on hand to connect to the network via alternate interface and path.  I disabled the Intel Ethernet adapter and connected with the Wireless adapter.

Bingo, no problem at all connecting back to my unRAID server and also successful at browsing to the unRAID GUI interface.

So after that I uninstalled the Intel Ethernet adapter driver and reinstalled it to reset any config settings that the Windows updates might have affected to it. 

After removing the USB Wi-Fi dongle and rebooting back on the Ethernet LAN connection, wala! it now is back to normal and can connect to my unRAID server again as normal.

Problem solved.

Link to comment

You could also go into your hosts file on your windows 10 machine and add the address to the server.

 

"C:\Windows\System32\drivers\etc"

 

Like this:

 

192.168.1.(whatever your server IP is) tower

 

 

example:

# localhost name resolution is handled within DNS itself.

# 127.0.0.1      localhost

# ::1            localhost

192.168.1.109 tower

 

 

Then when you try and access your server via \\tower windows will know the correct IP.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.