seamusmcaffrey

Got it - lots of things to try! I likely won't be able to for a few days at minimum but this is lots to work with, thank you. I have tried accessing via IP address and //tower - neither work. I hadn't checked the network file again but I guess it's possible it got overwritten somehow; will double check! I've checked ifconfig eth0 and it was still returning an IP address - the same one as it did last night when it worked.

Sadly - I'm back. Last night I was able to log on immediately after turning "use DHCP" back on, so I shut down and figured I could deal with the rest of setup the next day. Unfortunately, I booted up the machine today to clean everything up and the Web GUI didn't work at all. It worked fine yesterday after reloading at http://tower ... I tried using several different ports (:8080,80,90, etc) and it still isn't connecting. So, not sure what's up. I've attached my go file and am happy to provide/try anything else if folks have ideas! go

I sure am! As mentioned, it worked fine and saw no reason to upgrade while it worked for my purposes. Anyways - great news - making me aware that this file exists enabled me to go in and poke in other config settings; I found that my config file was set to turn off DHCP, I'm sure I had a reason in the past to do it this way... turning this back on opened me up to perfectly usable IP address for access and we are back in! Turns out I'm on 5.0-rc12a. So I guess it's time to upgrade so I don't have this problem in the future Unless someone knows of a better resource, I'll follow the guide to get myself up to date now! Though I'd appreciate any warnings of potential data loss if that feels like a thing that could happen... but I can do more research from here. Thanks so much for ya'lls help!

I'm not sure what the "go file" or "emhttp" are but I'll google those things and have a look when I get home tonight! I tried accessing it at 80 and 90 based on some posts I saw that suggested those were default, I'll try 8080. my understanding of the way to do this is http://ip_address:8080 but let me know if that sounds wrong. Thanks for the ideas!

[Solved] It turns out my very old unraid install was setup with DCHP set to "off" and I assume the hardcoded IP's weren't playing nice with a different router system. We're back up and running. Unsolved. Back at trying to fix... Hey folks - longtime unraid user with very little troubleshooting knowledge. My box has been running smooth for years now until my wife dropped the machine (long story) and it wouldn't boot up anymore (sad). I made a new build to put the drives in and everything set up pretty smoothly, but can't get connected to Web GUI. I've set everything up and based on what I've read, just put the thumb drive into the machine. It's an older version of unraid - a few years at least, I think I last upgraded in 2014 (I know, I know - but if it ain't broke, don't fix it). Long story short, after some initial BIOS troubleshooting I've been able to get unraid running but Web GUI won't load from any of my browsers - the connection just times out. Things I've tried so far, based on posts I've been able to find ("network not working" troubleshooting guide provides little to help): * inet IP address shows up with ifconfig eth0 command; so I assume it isn't explicitly network access related (i.e. box is connected to internet) * tried //tower, //IP_address, http://tower, http://IP_address, the https versions of those in browser * tried the above in both safari and IE, and on mac (tower.local) and PC * this exact thumb drive worked previously in the old box so I know it's FAT32 formatted etc * OS thumb drive tried in all USB slots, same with ethernet cable * verified disks are being read / loaded with dmesg|grep SATA|grep link * tried removing the http→https forwarding using instructions i found here; didn't seem like the best way to do this, but not sure how else to try * ran df command and have a photo of it if helpful but ran out of time to write & capture the syslog file for that attempt at this * have NOT yet run memtest but I'm not sure that helps this kind of issue? reason I haven't tried that yet is because the computer starts screeching (I'm pretty sure it's high CPU/mobo temp alarm based on "sensors" readout) - so I'm reluctant to let the computer just run memtest all day in case I cook my gear. I was hoping to get things up and running and get access to my old data before troubleshooting what's causing the screeching. As I mentioned, it's an old version of unraid but I'm afraid of upgrading given how much data is still on the hard drives. If that might be my problem, I can try that next but didn't want to risk losing data - I've found very little on whether or not this is a risky move (upgarding hardware and OS at the same time). Syslog is attached and am happy to try to produce whatever else I can to troubleshoot. Thanks so much in advance for any help folks can provide! syslog

alrighty.. rule one in tech support; restart the machine and see if it solves the problem. restarting seemed to solve the problem. i was mostly confused because the powerdown command wasn't actually turning it off.. anyways i'm letting it run parity check now to see if there's issues; startup log is attached in case someone wants to see if they see red flags for anything thanks! 121814_syslog.txt

So, first off.. I'm not good at running this; I got it up and running and haven't touched it much since. So I apologize if I don't know how to properly describe what's going on. Anyway, Server has been online since literally June with no errors. Worked fine earlier this morning and then suddenly I couldn't access it in windows explorer anymore (it hangs/crashes explorer). So I started investigating. Naturally, my system log is behemoth having been on that long... but these are the things I'm seeing. Running 5.0-rc12a since that's been stable for me. -If I log on via telnet, and try to send poweroff command, it sees it - but does not turn off -it seems to be repeating a "self detected stall on CPU" error Apologies but I don't know how to make it a "text box" within the post and my notepad is now crashing also, I don't want to lose the log so it's pasted below. /usr/bin/tail -f /var/log/syslog Dec 18 22:45:12 Tower kernel: [] vfs_rename_dir+0xc0/0x122 Dec 18 22:45:12 Tower kernel: [] vfs_rename+0xc5/0x1d5 Dec 18 22:45:12 Tower kernel: [] ? do_path_lookup+0x1e/0x50 Dec 18 22:45:12 Tower kernel: [] sys_renameat+0x17d/0x1ee Dec 18 22:45:12 Tower kernel: [] ? user_path_create+0x40/0x49 Dec 18 22:45:12 Tower kernel: [] ? sys_mkdirat+0x21/0x93 Dec 18 22:45:12 Tower kernel: [] sys_rename+0x28/0x2a Dec 18 22:45:12 Tower kernel: [] syscall_call+0x7/0xb Dec 18 22:45:26 Tower in.telnetd[18276]: connect from 192.168.1.172 (192.168.1.172) Dec 18 22:45:28 Tower login[18277]: ROOT LOGIN on '/dev/pts/2' from '192.168.1.172' Dec 18 22:48:12 Tower kernel: INFO: rcu_sched self-detected stall on CPU { 0} (t=366060 jiffies) Dec 18 22:48:12 Tower kernel: Pid: 13140, comm: shfs Tainted: G O 3.4.36-unRAID #1 Dec 18 22:48:12 Tower kernel: Call Trace: Dec 18 22:48:12 Tower kernel: [] print_cpu_stall+0x6d/0xe5 Dec 18 22:48:12 Tower kernel: [] __rcu_pending+0x3b/0x138 Dec 18 22:48:12 Tower kernel: [] rcu_check_callbacks+0x76/0xa1 Dec 18 22:48:12 Tower kernel: [] update_process_times+0x2d/0x58 Dec 18 22:48:12 Tower kernel: [] tick_periodic+0x63/0x65 Dec 18 22:48:12 Tower kernel: [] tick_handle_periodic+0x19/0x6f Dec 18 22:48:12 Tower kernel: [] smp_apic_timer_interrupt+0x6d/0x7f Dec 18 22:48:12 Tower kernel: [] apic_timer_interrupt+0x2a/0x30 Dec 18 22:48:12 Tower kernel: [] ? reiserfs_parse_alloc_options+0x454/0x454 Dec 18 22:48:12 Tower kernel: [] ? reiserfs_discard_all_prealloc+0x2d/0x3c Dec 18 22:48:12 Tower kernel: [] do_journal_end+0x1b4/0x968 Dec 18 22:48:12 Tower kernel: [] journal_end+0xb7/0xbf Dec 18 22:48:12 Tower kernel: [] reiserfs_rename+0x859/0x879 Dec 18 22:48:12 Tower kernel: [] ? find_busiest_group+0x283/0x998 Dec 18 22:48:12 Tower kernel: [] ? sched_clock_local+0x12d/0x17c Dec 18 22:48:12 Tower kernel: [] vfs_rename_dir+0xc0/0x122 Dec 18 22:48:12 Tower kernel: [] vfs_rename+0xc5/0x1d5 Dec 18 22:48:12 Tower kernel: [] ? do_path_lookup+0x1e/0x50 Dec 18 22:48:12 Tower kernel: [] sys_renameat+0x17d/0x1ee Dec 18 22:48:12 Tower kernel: [] ? user_path_create+0x40/0x49 Dec 18 22:48:12 Tower kernel: [] ? sys_mkdirat+0x21/0x93 Dec 18 22:48:12 Tower kernel: [] sys_rename+0x28/0x2a Dec 18 22:48:12 Tower kernel: [] syscall_call+0x7/0xb Dec 18 22:48:42 Tower shutdown[18301]: shutting down for system halt Dec 18 22:51:12 Tower kernel: INFO: rcu_sched self-detected stall on CPU { 0} (t=384063 jiffies) Dec 18 22:51:12 Tower kernel: Pid: 13140, comm: shfs Tainted: G O 3.4.36-unRAID #1 Dec 18 22:51:12 Tower kernel: Call Trace: Dec 18 22:51:12 Tower kernel: [] print_cpu_stall+0x6d/0xe5 Dec 18 22:51:12 Tower kernel: [] __rcu_pending+0x3b/0x138 Dec 18 22:51:12 Tower kernel: [] rcu_check_callbacks+0x76/0xa1 Dec 18 22:51:12 Tower kernel: [] update_process_times+0x2d/0x58 Dec 18 22:51:12 Tower kernel: [] tick_periodic+0x63/0x65 Dec 18 22:51:12 Tower kernel: [] tick_handle_periodic+0x19/0x6f Dec 18 22:51:12 Tower kernel: [] smp_apic_timer_interrupt+0x6d/0x7f Dec 18 22:51:12 Tower kernel: [] apic_timer_interrupt+0x2a/0x30 Dec 18 22:51:12 Tower kernel: [] ? __discard_prealloc+0x10/0xab Dec 18 22:51:12 Tower kernel: [] reiserfs_discard_all_prealloc+0x2d/0x3c Dec 18 22:51:12 Tower kernel: [] do_journal_end+0x1b4/0x968 Dec 18 22:51:12 Tower kernel: [] journal_end+0xb7/0xbf Dec 18 22:51:12 Tower kernel: [] reiserfs_rename+0x859/0x879 Dec 18 22:51:12 Tower kernel: [] ? find_busiest_group+0x283/0x998 Dec 18 22:51:12 Tower kernel: [] ? sched_clock_local+0x12d/0x17c Dec 18 22:51:12 Tower kernel: [] vfs_rename_dir+0xc0/0x122 Dec 18 22:51:12 Tower kernel: [] vfs_rename+0xc5/0x1d5 Dec 18 22:51:12 Tower kernel: [] ? do_path_lookup+0x1e/0x50 Dec 18 22:51:12 Tower kernel: [] sys_renameat+0x17d/0x1ee Dec 18 22:51:12 Tower kernel: [] ? user_path_create+0x40/0x49 Dec 18 22:51:12 Tower kernel: [] ? sys_mkdirat+0x21/0x93 Dec 18 22:51:12 Tower kernel: [] sys_rename+0x28/0x2a Dec 18 22:51:12 Tower kernel: [] syscall_call+0x7/0xb

yep, gonna call this one fixed. thanks all for your help!

yep, I'm gonna call this one solved. seems to be working like a charm. now to fix my xbmc issue.... THANK YOU ALL!

against all odds whatever i've done appears to have worked... will do some more checks and then switch post to solved. thanks all for your input... note to others: the error I was seeing appears to be fixed by going to tower: properties - advanced - change permissions - check both boxes ("Include inheritable permissions from this object's parent" and "Replace all child object permissions with inheritable permissions from this object" ) Then I just applied and let it run. so far it's letting me change/delete/move things that I previously couldn't...

I think that's what they were, I feel like I saw that somewhere... I haven't really been sure what to do but I was stumbling around in windows security so I tried to send permissions using the following dialogs (inherit from parent)... I don't really know what this'll do... but nothing else has been working so...

well no i never bothered adding a user since i'm the only one that uses the machine. that being said, would adding a user now even do anything? all of the other files were originally written there as root, and i probably can't do anything about them. i'm trying to overwrite permissions now using windows utilities... it hasn't thrown an error yet but it'll take forever to run through everything; we'll see what happens. i did try putting a user on the unraid box but nothing seemed to happen or change... just now...

yes when i first updated i ran the utility, and i tried running it again a few days ago when i set out to fix this problem once and for all

Just tried, thanks for the suggestion. Should have done that already. BUT... no, still no luck. still can't modify anything.

update, figured out how to change unraid workgroup. I changed the unraid workgroup name so that it's the same as the windows machine it's sharing with over smb and changed local master to yes... still no dice.