rxnelson Posted December 2, 2016 Share Posted December 2, 2016 I have a server that was "rock solid" on 5.05. I recently upgraded it to the latest version through the plugin. All seemed well. Now, twice in I'd guess the last month the server becomes inaccessible via \\tower from the "run" line in windows. I can still see it through the webGUI. It happened again tonight. I stopped the array and restarted it. That seemed to fix the issue for now. I searched a bit and have seen that people set the server as the local SMB master? I am not sure this is the same issue though. I have attached the diagnostics info. Any ideas? tower-diagnostics-20161201-2135.zip Quote Link to comment
trurl Posted December 2, 2016 Share Posted December 2, 2016 If you can access it by \\ip.address but not by \\tower then making unRAID SMB master is the usual fix. Quote Link to comment
rxnelson Posted December 2, 2016 Author Share Posted December 2, 2016 If you can access it by \\ip.address but not by \\tower then making unRAID SMB master is the usual fix. What if I have two Unraid servers? Just pick one? Just a thought, maybe introducing the second one hosed things up? Quote Link to comment
trurl Posted December 2, 2016 Share Posted December 2, 2016 If you can access it by \\ip.address but not by \\tower then making unRAID SMB master is the usual fix. What if I have two Unraid servers? Just pick one? Just a thought, maybe introducing the second one hosed things up? You haven't named both of the "tower" have you? Quote Link to comment
rxnelson Posted December 3, 2016 Author Share Posted December 3, 2016 Tower and towertest Sent from my iPhone using Tapatalk Quote Link to comment
rxnelson Posted December 4, 2016 Author Share Posted December 4, 2016 If you can access it by \\ip.address but not by \\tower then making unRAID SMB master is the usual fix. I did this and the behavior is the same. Any other ideas? Something go wonky in the upgrade? Quote Link to comment
rxnelson Posted December 5, 2016 Author Share Posted December 5, 2016 The shares have become inaccessible twice today. The webgui still worked. Attempting a diagnostics during this time resulted in a 404 error. I rebooted the first time and the second time just stopped and started the array. Attaching the diagnostics from after the second time. Any help is appreciated. tower-diagnostics-20161204-2317.zip Quote Link to comment
trurl Posted December 5, 2016 Share Posted December 5, 2016 Are all of your plugins up-to-date? Probably unrelated to your problem, but there is this in your syslog: Dec 4 17:05:45 Tower ntpd[1440]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized Does you server have the correct time? Quote Link to comment
rxnelson Posted December 9, 2016 Author Share Posted December 9, 2016 Are all of your plugins up-to-date? Probably unrelated to your problem, but there is this in your syslog: Dec 4 17:05:45 Tower ntpd[1440]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized Does you server have the correct time? The plugins are up to date. The server time looks OK in the webgui. I stopped the array and \\tower and regained access to shares for about 2 minutes and then it went "offline" again. I'm just not sure here. Quote Link to comment
rxnelson Posted December 9, 2016 Author Share Posted December 9, 2016 Do you think it would be worthwhile to start from scratch? I was going to replace the mobo/cpu anyway. I have been reading up on how to start over but save the drive configuration/data. Quote Link to comment
rxnelson Posted December 9, 2016 Author Share Posted December 9, 2016 Sorry to keep bumping my own thread but I just noticed a ton of these "dynamix.system.stats" entries in the log. This doesn't look normal to me? It has an entry about every minute for literally days. ec 6 19:31:08 Tower kernel: mdcmd (51): spindown 1 Dec 6 19:31:08 Tower kernel: mdcmd (52): spindown 2 Dec 6 19:31:10 Tower kernel: mdcmd (53): spindown 11 Dec 6 19:32:01 Tower crond[1456]: exit status 2 from user root /usr/local/emhttp/plugins/dynamix.system.stats/scripts/sa1 1 1 &>/dev/null Dec 6 19:33:01 Tower crond[1456]: exit status 2 from user root /usr/local/emhttp/plugins/dynamix.system.stats/scripts/sa1 1 1 &>/dev/null Dec 6 19:34:01 Tower crond[1456]: exit status 2 from user root /usr/local/emhttp/plugins/dynamix.system.stats/scripts/sa1 1 1 &>/dev/null Dec 6 19:35:01 Tower crond[1456]: exit status 2 from user root /usr/local/emhttp/plugins/dynamix.system.stats/scripts/sa1 1 1 &>/dev/null Dec 6 19:36:01 Tower crond[1456]: exit status 2 from user root /usr/local/emhttp/plugins/dynamix.system.stats/scripts/sa1 1 1 &>/dev/null Dec 6 19:37:01 Tower crond[1456]: exit status 2 from user root /usr/local/emhttp/plugins/dynamix.system.stats/scripts/sa1 1 1 &>/dev/null Dec 6 19:38:01 Tower crond[1456]: exit status 2 from user root /usr/local/emhttp/plugins/dynamix.system.stats/scripts/sa1 1 1 &>/dev/null Dec 6 19:39:01 Tower crond[1456]: exit status 2 from user root /usr/local/emhttp/plugins/dynamix.system.stats/scripts/sa1 1 1 &>/dev/null Dec 6 19:40:02 Tower crond[1456]: exit status 2 from user root /usr/local/emhttp/plugins/dynamix.system.stats/scripts/sa1 1 1 &>/dev/null Dec 6 19:41:01 Tower crond[1456]: exit status 2 from user root /usr/local/emhttp/plugins/dynamix.system.stats/scripts/sa1 1 1 &>/dev/null Dec 6 19:42:01 Tower crond[1456]: exit status 2 from user root /usr/local/emhttp/plugins/dynamix.system.stats/scripts/sa1 1 1 &>/dev/null Dec 6 19:42:23 Tower kernel: mdcmd (54): spindown 7 Dec 6 19:42:25 Tower kernel: mdcmd (55): spindown 4 Dec 6 19:42:26 Tower kernel: mdcmd (56): spindown 6 Dec 6 19:42:31 Tower kernel: mdcmd (57): spindown 3 Dec 6 19:42:32 Tower kernel: mdcmd (58): spindown 5 Dec 6 19:42:38 Tower kernel: mdcmd (59): spindown 8 Dec 6 19:42:38 Tower kernel: mdcmd (60): spindown 9 Dec 6 19:42:39 Tower kernel: mdcmd (61): spindown 10 Dec 6 19:42:39 Tower kernel: mdcmd (62): spindown 12 Dec 6 19:42:40 Tower kernel: mdcmd (63): spindown 13 Dec 6 19:43:01 Tower crond[1456]: exit status 2 from user root /usr/local/emhttp/plugins/dynamix.system.stats/scripts/sa1 1 1 &>/dev/null Dec 6 19:44:01 Tower crond[1456]: exit status 2 from user root /usr/local/emhttp/plugins/dynamix.system.stats/scripts/sa1 1 1 &>/dev/null Dec 6 19:45:01 Tower crond[1456]: exit status 2 from user root /usr/local/emhttp/plugins/dynamix.system.stats/scripts/sa1 1 1 &>/dev/null Dec 6 19:46:01 Tower crond[1456]: exit status 2 from user root /usr/local/emhttp/plugins/dynamix.system.stats/scripts/sa1 1 1 &>/dev/null Dec 6 19:47:16 Tower crond[1456]: exit status 2 from user root /usr/local/emhttp/plugins/dynamix.system.stats/scripts/sa1 1 1 &>/dev/null Quote Link to comment
rxnelson Posted December 9, 2016 Author Share Posted December 9, 2016 Hmmmm....not sure if you are telling me to search better or you pointed me to the fix. Tricky!!! I had already uninstalled the stats. I'll wait and see if somehow that was related to the shares dying before reinstalling. Quote Link to comment
rxnelson Posted December 9, 2016 Author Share Posted December 9, 2016 Network access went down again. Not much to go on in the log. It looks like the drives spun down and that was about it. Also, intermittently windows will ask for my user/pass on this server even though nothing is set. Dec 8 21:02:48 Tower root: plugin: running: anonymous Dec 8 21:02:59 Tower emhttp: cmd: /usr/local/emhttp/plugins/dynamix.plugin.manager/scripts/plugin remove dynamix.system.stats.plg Dec 8 21:02:59 Tower root: plugin: running: anonymous Dec 8 21:03:20 Tower emhttp: cmd: /usr/local/emhttp/plugins/dynamix.plugin.manager/scripts/plugin remove ca.backup.plg Dec 8 21:03:20 Tower root: plugin: running: anonymous Dec 8 21:03:29 Tower emhttp: cmd: /usr/local/emhttp/plugins/dynamix.plugin.manager/scripts/plugin remove ca.cleanup.appdata.plg Dec 8 21:03:29 Tower root: plugin: running: anonymous Dec 8 21:03:35 Tower emhttp: cmd: /usr/local/emhttp/plugins/dynamix.plugin.manager/scripts/plugin remove community.applications.plg Dec 8 21:03:35 Tower root: plugin: running: anonymous Dec 8 21:09:30 Tower kernel: mdcmd (50): spindown 0 Dec 8 21:09:31 Tower kernel: mdcmd (51): spindown 1 Dec 8 21:09:32 Tower kernel: mdcmd (52): spindown 2 Dec 8 21:09:32 Tower kernel: mdcmd (53): spindown 3 Dec 8 21:09:32 Tower kernel: mdcmd (54): spindown 4 Dec 8 21:09:33 Tower kernel: mdcmd (55): spindown 5 Dec 8 21:09:34 Tower kernel: mdcmd (56): spindown 6 Dec 8 21:09:34 Tower kernel: mdcmd (57): spindown 7 Dec 8 21:09:35 Tower kernel: mdcmd (58): spindown 11 Dec 8 21:59:28 Tower kernel: mdcmd (59): spindown 4 Dec 8 21:59:29 Tower kernel: mdcmd (60): spindown 6 Dec 8 22:06:03 Tower kernel: mdcmd (61): spindown 3 Dec 8 22:06:03 Tower kernel: mdcmd (62): spindown 5 Dec 8 22:20:34 Tower kernel: mdcmd (63): spindown 8 Dec 8 22:20:34 Tower kernel: mdcmd (64): spindown 9 Dec 8 22:20:35 Tower kernel: mdcmd (65): spindown 10 Dec 8 22:20:35 Tower kernel: mdcmd (66): spindown 12 Dec 8 22:20:36 Tower kernel: mdcmd (67): spindown 13 Dec 8 23:30:24 Tower emhttp: cmd: /usr/local/emhttp/plugins/dynamix/scripts/tail_log syslog Dec 8 23:30:56 Tower emhttp: cmd: /usr/local/emhttp/plugins/dynamix/scripts/tail_log syslog Quote Link to comment
rxnelson Posted December 24, 2016 Author Share Posted December 24, 2016 I think this may be solved. I only had 1 gig of ram in the server but I don't think that is enough for a NAS even though that is what the recommendations say. I found through the fix common problems app that rootfs was 100% full. I threw in another 2 gigs of ram and now rootfs is at 25% and the server has been up and acting normal for a week or so. Quote Link to comment
Recommended Posts
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.