Kaveh

Yes, but does it need to? Why can’t local access remain unredirected?

It would be nice to walk back this plugin a little bit. I originally installed it because of the automated USB key backup. It seems like that feature should be isolated from the SSL/redirect feature. You should be able to use one without the other.

Yes, but local access redirects to the unraid.net SSL URL. It should use SSL for remote connections, but it shouldn't redirect local connections.

It shouldn't redirect at all (unless you specify it should). That's my point.

I'd rather go to my `tower.local` address and have it remain there rather than redirecting to `*.unraid.net`. There doesn't seem to be any option I can find to turn this redirect off. Is the only way to use the IP address?

Is there any way to prevent the redirect from the local IP or local name to the unraid.net name?

Woke up today with the webgui not properly loading. I pulled the flash drive and tried to mount it on my macbook to no avail. When I try to boot it again on my unraid machine, it doesn't seem to think it's bootable anymore. It seems like the flash drive itself might have become corrupted (though I have no idea how, it's a Sandisk Ultra). Does anyone know of anything I can try to make this work again? Short of that, how do I get to my array again?

Do I have to go set this for each disk? I set it to bfq in the disk settings, but it didn’t seem to work. I’m specifically looking at my array disks and trying to make it so that read throughout doesn’t tank when the array is being written to (by the mover).

Any thoughts on this?

I tried changing the scheduler in the disk settings page to `bfq`, but even after a reboot, when SSHing in to confirm the scheduler has not changed, I get:

Has anyone tried the 6.7.3 release candidates? It looks like a new kernel and md/unraid version in rc3.

I'm having issues with loading up transmission after the latest update (today): /usr/local/Transmission/usr/bin/transmission-daemon: error while loading shared libraries: libevent-2.0.so.5: cannot open shared object file: No such file or directory

Plugin pages for Phaze plugins (such as plex, sickbeard, transmission, etc) aren't showing after installing beta12. Is this a known issue?

Yup....no support or response whatsoever. What am I supposed to do?

You emailed me on 12:00 on a Sunday and I took an hour and a half to reply - I don't think this is "to no avail". Get it into the failing state on Monday and then send an email and we can debug it. My apologies if that is the case, but it seems I never got your email (even checked the spam folders). Today's email was not the first time I used the online form. Prior to that I sent an email in September 2013 and one in November of 2013 to [email protected], neither of which got a reply. I also have not received an email today. The only responses I've gotten have been through this forum posting alone. This has continued to be a problem for me across many of the recent unraid releases, and I lack the familiarity with unraid and shfs to be able to debug it alone. It has been extremely frustrating for me because of the nearly daily need to take down and bring up my array. Hi Tom, Once again I seem to have completely lost contact with you over email. I sent you logs on 1/18 and haven't even heard so much as a confirmation that you received them, despite regularly checking in. Is there some other route I need to take to get support?

I have unraid running plex on a cache drive. I'd ideally like to get it into a bad state again and with Tom's help see if the root cause can be found.

You emailed me on 12:00 on a Sunday and I took an hour and a half to reply - I don't think this is "to no avail". Get it into the failing state on Monday and then send an email and we can debug it. My apologies if that is the case, but it seems I never got your email (even checked the spam folders). Today's email was not the first time I used the online form. Prior to that I sent an email in September 2013 and one in November of 2013 to [email protected], neither of which got a reply. I also have not received an email today. The only responses I've gotten have been through this forum posting alone. This has continued to be a problem for me across many of the recent unraid releases, and I lack the familiarity with unraid and shfs to be able to debug it alone. It has been extremely frustrating for me because of the nearly daily need to take down and bring up my array.

Is it possible to get support for this? I emailed the support address on the lime-tech site but to no avail. I am a paying customer and I would be happy to help debug this issue, but it seems there is little to no support. It's at the point where I have to basically stop the array and 'killall shfs' once a day, then start everything again. The moment I 'killall shfs', everything (crashplan, plex, sabnzbd) become responsive again. If I can't resolve this issue with Unraid, I'm going to put in the effort to migrate my NAS to Ubuntu.

I feel that this has something to do with a bug in shfs. The moment I kill shfs, all the other processes (i.e. Plex, Crashplan, Sickbeard) become responsive again. shfs appears to be holding something up. I'd be happy to help debug, but I don't know enough about unraid to know where to start. Does anyone have any ideas?

Just a standard troubleshooting technique - half splitting. Once I isolated that it was some plugin causing the issue by disabling all plugins, I then proceeded to add half back in, and seeing if the issue continued. If it did, then I knew my issue was within those group that was turned on - so I disabled half again and kept going until I isolated it to one specific plugin. From there, I looked through sickbeard's logs carefully. Half split is useful for single variable troubleshooting - and it's fast, but it's a bit less accurate if you have multiple variables causing your issue. Right, I guess I was wondering how you determined it was due to the apple metadata and sickbeard's consumption of it. Seems like a bug in sickbeard that needs to be handled if this is the root cause.

Wow...interesting...I'll try removing all instances of those and see if my problem goes away. How did you figure it was sickbeard choking?

I don't understand. What do you mean by this question? Rebooting a server nearly daily is not problematic?

Yes, I'm on the 5.0 release (now). I still exhibit this issue and it's been extremely frustrating. After 'killall shfs', I effectively have to shut down my array and reboot the server almost daily to get it to come back up.

To the top... I really need some help. If I can't figure this out, I'm might just invest a weekend and move my NAS over to ubuntu (though I'd really prefer to stick with unraid). Why is it when I kill 'shfs' everything starts responding again?

Zombie processes are already dead and other than taking a tiny bit of memory, do no harm. Unix/Linux let the parent process read the exit status of a child process. when a child process ends, if a parent process has not yet read the exit status, but the parent process still exists, it will show as a zombie process. The issue is with the parent process not doing its "read" of the child process exit status. (That tiny bit of memory I was talking about is the exit status of the child process). In other words... blame plex media server, not unRAID and don't be afraid of zombies... It is not as if they are hanging, they are already dead, the parent process has just not cared. I've already brought it up in the plex forums. This problem doesn't exist on any other platforms running plex as best as I can tell. Regarding the parent processes, the parent to all the processes I try to kill that eventually turn into zombies is 'init'. The only time I've been able to successfully get rid of the zombie processes is when I manually kill 'shfs'. Doesn't it seem like shfs might not be allowing the parent process time to read the exit status?