gregoryx

Thank you for clarifying.

I'm having similar issues. I removed SF after getting the freeze a couple revs back; then put it back recently only to have the freezes resume. Can someone tell me how to restart emhttp (or whatever might work) when this freeze occurs - so I don't need to do a full reboot? The system is working in every other way. The old "killall emhttp" and "nohup /user/local/emhttp &" does not work on v5 systems.

Success! Formatted again. Copied over RC10 (not RC11). Did make_bootable.bat. Copied over config. Did NOT copy over plugins (only thing in there was SimpleFeatures - can't recall if I copied it over last time). Came up. Rebuilding parity now. At about 95MB per second. Not sure if it was the RC10 versus RC11 or the nth time of reformatting or if I screwed up and restored SimpleFeatures last time. I'll put it all back together one piece at a time after the rebuild. Thank you for the amazingly prompt help.

Ugh. I was feeling all optimistic - of course! reformat! - but no luck. Same results. Formatted the USB key. Copied over RC11 files. Copied over my config files into the config dir. Did make_bootable.bat. Same result. Hmm... try it without the configs?

RC11 was acting weird in the web gui (slow to no response). I couldn't get it to gracefully shut down, so I forced it from the command line (shutdown) and replaced the bzimage and bzroot from RC10 using a Windows PC then rebooted. Nothing. Sits dead after a "Loading Operating System" prompt (which I assume is from the BIOS). I've done the "make_bootable" a couple of times (on the Windows PC) and same results. Rolled back to saved files from the USB in RC8a. Same thing. Not sure what to do next. HELP?

Download not working for me. Is it working for everyone else?

I'm getting these on the latest "RC8" version. How did you resolve this?

Moved from 4.7 to 5.0-rc8a a couple of weeks ago. Finally got the shares issue worked out (replaced the SMB driver thingy - thanks for the help). Now getting to these annoying emails I get every hour. I'm getting emails that look just like the ones I /USED/ to get on 4.7 when the monthly parity resync would run. I think I may have checked / turned on some hourly notification thing when I first loaded 5.0-rc8a, but then I loaded the SimpleFeatures UI and can't figure out where that "hourly notification" thing went. In case that's not the only issue: resync is NOT running (the drives power down) and I've turned off the notification functions I see in the SimpleFeatures UI. Prolly a really simple thing... help?

Well, I'll be... that seems to have worked! Thank you, thank you, thank you! ;D It doesn't seem to be ripping fast or anything... but it seems to be working. I'll test sync'ing up my backups... that's always a good read/write test. Fingers crossed!

Bump. I've re-run the permissions script. I have the same results. On three different machines (one each of XP, Win7, Win8), if I attempt to attach to a share that the user does NOT have rights to, I am unable to attach (as expected). If the user /should/ have rights, I'm able to see the files. If I attempt to WRITE a file, small files succeed (~100K or so) and everything larger fails. I'm not sure where I should be looking or what I should be trying to change at this point.

Thanks for all the help, guys. I'm still having the same issues. I've wiped the users and rebuilt them. I've changed settings in the shares many times. If I set shares so that I should /not/ be able to access them, then reboot the PCs, it acts accordingly. At least in the Win8 system, I don't have to reboot, just kill the connections with net use /delete. What I'm experiencing is very... odd. When attached as a user who /should/ have rights, I can delete or rename any file. I cannot copy a file to the share from a PC. In Win8 and Win7, it does it's "calculating" thing, maybe says "20% progress", then kicks an error about the server not being available ("There is a problem accessing \\unraid1\temp" in Win7). Of course, it is. Occasionally (haven't found a pattern yet), the file then shows as being present in the share and I can see it from another system at that point and it appears to be full size. It is, of course, corrupt / not valid. I can copy a very small file (< 100KB) and it will work. But anything over those small sizes, it does the "calculating" thing, then fails - either with a small "percent complete" on the indicator or not.

dgaschk, I ran the short smart tests the other day and some had stuff reporting, but nothing fatal. the parity is clean. running the long test on the parity drive now. you thinking I should run the short or long? and is there a way to run them on all drives - similar to the way the bubba interface did in 4.7? I assume loading bubba is not the way to go with 5.0...

The output from that first one was... uh... crazy long. Every FILE shows: -rw-rw---- 1 nobody users Every FOLDER shows: drwxrwx 1 nobody users Settings for eth0: Supported ports: [ TP ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Advertised pause frame use: Symmetric Receive-only Advertised auto-negotiation: Yes Speed: 1000Mb/s Duplex: Full Port: Twisted Pair PHYAD: 0 Transceiver: internal Auto-negotiation: on MDI-X: Unknown Supports Wake-on: pumbg Wake-on: g Current message level: 0x00000033 (51) Link detected: yes root@UNRAID1:~# ifconfig eth0 Link encap:Ethernet HWaddr 6c:f0:49:e7:58:c8 inet addr:192.168.253.5 Bcast:192.168.253.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:111614 errors:0 dropped:6 overruns:0 frame:0 TX packets:234748 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:17223863 (16.4 MiB) TX bytes:215225435 (205.2 MiB) Interrupt:48 Base address:0x6000 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:9 errors:0 dropped:0 overruns:0 frame:0 TX packets:9 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:646 (646.0 B) TX bytes:646 (646.0 B)

I grabbed this from the "system log" button in the menu. If there's a better / more thorough way, let me know. After reboot (and wandering off with some honey-dos), I started the array and tried unsuccessfully to copy a file from two different PCs using a "public" share called temp. They both failed to write. The XP error is "Cannot copy filename.ext: The specified network name is no longer available. Reading from both clients works great. Quite fast, in fact. syslog_unraid.txt

Thanks, Helmonder. The client machines are using various user names. I've tried with "public" shares (presumably don't need login authorization?) and with users that authenticate on other shares. I say that is's "mostly" because it seems like sometimes I can drop / write a file, but in the rare case that it succeeds it takes a LONG time to get around to doing so. I do not have my cache drive enabled right now. Not sure if that'd have THIS kind of effect.