death.hilarious

Thanks @bonienl for the help. I ended up just deleting the passwd/shadow files from flash drive and starting over. I didn't have a large number of user or anything, so it wasn't a big deal.

That's interesting. On my end the /etc/passwd file has: root:$5$Qc3qR/iwOba/$Xz11Q9/FYai01GaR3evP3Q0emXJ2cGD0eG/ONjbQjV5:0:0:Console and webGui login account:/root:/bin/bash and my /etc/shadow has: root:x:0:0:Console and webGui login account:/root:/bin/bash Seems like it's reversed somehow, with the password hash in the passwd file and 'x' in the shadow. Can I just swap those lines without screwing anything up?

When I try to set the password through the WebGUI one of two things happen: 1. after clicking submit the webgui becomes completely unresponsive (connection refused error), and won't work until I reboot the server through SSH; OR 2. seems to work without a problem and I see this in the log: Oct 15 09:15:22 unRAID emhttp: shcmd (226): chpasswd <<< 'root':***** Oct 15 09:15:22 unRAID emhttp: shcmd (227): smbpasswd -L -s -a 'root' <<< *****$'\n'***** Oct 15 09:15:22 unRAID emhttp: shcmd (228): cp /etc/passwd /etc/shadow /var/lib/samba/private/smbpasswd /boot/config BUT even if I "successfully" change the root password through the GUI the no login prompt problem persists. I thought maybe the flash drive was getting corrupted (during the password change attempts that result in a crash) and being changed to read-only, so I removed the flash drive and did a chkdsk on it and there were no errors.

I think your unRAID license is tied to the physical flash drive. You can get lime-tech to transfer it to a new stick once a year for free: https://lime-technology.com/replace-key/

It's definitely not a stored credentials issue. I tested on multiple systems that I've never used to access the unRAID server (including my phone, a freshly formatted linux laptop, and windows desktop). My browsers always run in severe sandboxes that auto clear when I close the browser (so it would be fascinating if there was sandbox escape); but it's pretty clear there is just no authentication going on for web access.

This thread describes the same issue in v5 https://forums.lime-technology.com/topic/28585-unraid-50-web-if-no-longer-asks-for-password/

Now I'm able to update my root password successfully through the WebUI but it still doesn't fix the no login prompt for Web console access.

unRAID v.6.3.5 I tried changing the unRAID root password using the WebUI, but something went wrong and the session crashed after submitting the password. When I reloaded the WebUI I couldn't log in using the old or new password. Since I still had SSH access, I tried to manually change the root password using the following commands: passwd cp /etc/passwd /etc/shadow /boot/config/ reboot After rebooting, the WebUI now no longer prompts for a password. I've confirmed on multiple browsers on multiple devices, so it's not a cookie issue. How can I restore the login prompt for the WebUI?? Any help would be appreciated!

And the official Sickrage repository is back up.... https://github.com/SickRage/SickRage

The General tab, which is unavailable, contains the API key and a bunch of other essential settings. Is there a way to bypass the cosmetic error?

Alternatively, you can use https://donna.devices.wvvw.me/sickrage/sickrage.git if the distortion.io link is slow... EDIT: Source: https://www.reddit.com/r/sickrage/comments/6p676l/temporarty_dmcafix_for_you_running_sickrage_in_a/

That's a huge plus for me. I've no doubt the tonidoid domain security is probably a bit sketchy, but it's infinitely better than having your home server show up on Shodan.

Private Internet Access introduced a new port forwarding API on February 2nd. Importantly:

+1

Anyone else running into this problem? 2016-08-21 11:11:57 POSTPROCESSER :: [50e350e] Exception generated in thread POSTPROCESSER: error 2 : No such file or directory Basically, I've got a post-processing directory full of stuff and Sickrage isn't processing the files for some reason. I've recently upgraded to unRAID 6.2 (latest RC) and suspect permissions might have something to do with it. Docker volumes are all properly mapped etc. and I've tried removing the docker (+delete image) and reinstalling. Could be an error with Sickrage since manual post-processing is throwing up funky python errors. Is there any special steps that need to be taken during the 6.1->6.2 migration? EDIT: I think I may have accidentally "updated" Sickrage through the web interface. I suspect the latest commits broke something. If you're like me and you get antsy when you see you're many commits behind, it's probably a good idea to disable the update notifications and trust Binhex to keep us reasonably up to date--especially considering that the Sickrage crew has a nasty habit of breaking things regularly.

The odd part is that i didn't even have the LAN_RANGE network variable in my config. I had to ADD LAN_NETWORK rather. It would not start properly without this added variable. Working for me too! Is it not possible to update the container description (which still describes LAN_RANGE)? If not, Lime Tech really needs to fix that...

WebUI for DelugeVPN has been inaccessible after the last two updates. Logs don't seem to show anything suspicious. For what it's worth, I've tried changing the environment variable LAN_RANGE to LAN_NETWORK as suggested by femin above--but that didn't fix it. Is this happening for anyone else or is it just me?

Sickrage wasn't working for me either. I think it was a problem with Sickrage (or so it seemed from the log errors). Sickrage development situation seems f'd up at the moment, most of the team left to start a new fork after the original developer came back. I ended up switching to the linuxserver.io docker (they've decided to move to the new fork).

Thanks for the clarification, binhex! Edit: I just took a look at the IP tables in the delugevpn docker and if understand them correctly, I think they effectively prevent the port forwarding attack. Nice work!!!

Just a FYI for PIA users: There was a vulnerability that allowed IP address to be leaked when port forwarding is enabled: https://www.perfect-privacy.com/blog/2015/11/26/ip-leak-vulnerability-affecting-vpn-providers-with-port-forwarding/ PIA seems to have patched servers to fix the problem and nothing further needs to be done for OpenVPN users: https://www.privateinternetaccess.com/forum/discussion/comment/34571/#Comment_34571 Users who connect through the PIA client should update to the latest clients (v.53) released today: https://www.privateinternetaccess.com/forum/discussion/19391/updated-mac-windows-and-linux-clients-v-53-released#latest

Mine does the same, I gave up and went back to using Bliss. I'm in the same boat as the two of you. After getting into the container and running beets, the program doesn't respond to any keyboard commands so I end up stuck at the first prompt. I thought it might be a putty issue, but I'm having the same problem from a linux terminal.

Binhex put better instructions in the FAQ post. Note particularly the LAN_RANGE environment variable in the DelugeVPN docker configuration (I guess you need to allow connections from your unraid server IP, even if it's technically connecting to itself). Also, for restarting Deluge, I just stopped and started the docker. You're using the correct credentials.

Ugh. I was having the same issue and eventually gave up and used a black hole directory. But because of your post I looked at it again and got it to work! You have to: 1) Enable remote connections to the daemon in Deluge (Preferences->Daemon->Allow Remote Connections) 2) Restart Deluge 3) In CouchPotato specify the host as <unRAID server IP>:58846 4) In CouchPotato get the username/password from the 'auth' file in the deluge app directory (the format of the auth file is username:password:permissions)

Thanks so much for the quick fix! I'm testing it now and it seems to be working fine. I'll post again if I run into any problems. Thanks again for all your work binhex, it's really appreciated. EDIT: I just checked and the latest MyScheduler plugin also appears to include the fix to core.py. MyScheduler is basically the standard scheduler with an option to force selected torrents to download, regardless of the scheduler (very handy).

Has anyone tried this possible fix for the Deluge scheduler issue? http://forum.deluge-torrent.org/viewtopic.php?f=9&t=52553