stealth82

The supported way is --bridge and you can change the HOST port in the WebGUI, sorry Too bad. I was hoping for it. Changing the webgui port doesn't really seem to be an option because the powerdown procedure invoked by the ups module works only when the port is none but 80. I don't know why but it's even commented right there in the file.

Thanks! any chance you could include the possibility to change the standard default port numbers to something different from port 80 and 443? (docker configured as host and not bridge).

Wait, I just realized it is my problem also. Why this limitation?

What about nginx? Has it been ported as well?

It happened to me this morning. I was alerted that the server was running on battery. I had to turn it off manually because the battery/minutes went lower than the threshold and despite the fact that the UPS printed "SHUTTING DOWN" nothing happened. I'm running unRAID 6.1.3

No, I could not access it from any computer. The webGUI was just not loading. That was before because now the webGUI is back online. I can easily guess that's because the docker finished updating while I was trying to figure out what to do So, now everything is working perfectly fine again It makes me wonder though: is that expected behavior or correct user experience?

I was updating my Plex container from my laptop. I left it unattended and the laptop went to sleep during the update... I can't gain access to the webGUI at the moment and I don't know what it is or it's been of the docker update process. What's the best thing to do in this case? This is what part of my ps command looks like. I mean, I think these are the related processes: root 13498 10211 0 16:38 ? 00:00:00 /usr/bin/php /usr/local/src/wrap_get.php plugins/dynamix.docker.manager/include/CreateDocker.php updateContainer=true&ct[]=pl root 13524 2 0 16:38 ? 00:00:01 [kworker/u8:2] root 13555 1507 0 16:39 ? 00:00:00 /bin/sh -c /usr/local/emhttp/plugins/dynamix/scripts/monitor &> /dev/null root 13556 13555 0 16:39 ? 00:00:00 /usr/bin/php /usr/local/emhttp/plugins/dynamix/scripts/monitor root 13557 13556 0 16:39 ? 00:00:00 wget -qO /dev/null 127.0.0.1:8080/update.htm?cmdStatus=apply

All the above instructions can be simplified into this: location / { proxy_pass http://tower; } And everything is going to work. I understand though that you wanted to slam the web gui under the /unraid subdirectory but it's not going to work because, well, because the web gui hasn't be written in a way that would make it play nicely with a reverse proxy in front of it. All that we can do is TO ASK that the web gui be rewritten with more relative URLs in its code. For the meantime you have to blow a FQDN for unraid alone as smdion suggested, which is not a bad idea in and of itself. But for these kind of things I would really like to slam all my apps under specific subdirectories like this: # THIS IS NOT FULLY WORKING. JUST HERE FOR EDUCATIONAL PURPOSES #location /unraid/ { # proxy_pass http://tower/; # proxy_set_header Host $host; # proxy_set_header X-Real-IP $remote_addr; # proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; # proxy_set_header X-Forwarded-Proto $scheme; #} # THIS IS WORKING 99% location /transmission/ { rewrite ^/transmission(/?)$ /transmission/web/ permanent; proxy_pass http://transmission:9091; proxy_pass_header X-Transmission-Session-Id; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } Transmission itself has a little problem that I'm still unable to solve but thanks to its unique URI (/transmission/) you can kind of fool it more easily. So this is the config I'm running at the moment (order is important): location /transmission/ { rewrite ^/transmission(/?)$ /transmission/web/ permanent; proxy_pass http://transmission:9091; proxy_pass_header X-Transmission-Session-Id; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } location / { proxy_pass http://tower; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } } I'm just hoping that one day they will make unRAID more reverse proxy compatible.

I don't.

I have no cache drive but that folder is present. I'm using 6.0-beta14b. I'm quite sure I didn't have it before but I can't remember till when. I also never had a cache drive before.

It's still there, only relocated in a different place. Click on the Info button on the menu bar.

Congrats!

Same thing occurred to me. But my operation was nastier. I swapped the parity disk with a data disk of the array I had previously emptied. Started a new config and the parity check is still in progress. 102 errors so far. Should I started getting worried?

Hi, I don't know if you can fix this but I encountered a problem with this http server, though it's very handy to install. If you feel like to, please give a look at this thread: http://lime-technology.com/forum/index.php?topic=21539.0

Try the following: set the spin down delay differently for those disks which won't spin down. Click on the particular disk and change the spin down delay value there, say make it shorter than default. To follow up: it worked. Thanks!

Try the following: set the spin down delay differently for those disks which won't spin down. Click on the particular disk and change the spin down delay value there, say make it shorter than default. Wow, that seems to be working now. Thank you very much!

Sorry if I quote this old post, but I'm having the same issue with two SAMSUNG HD204UI drives I recently added to my configuration. All the other disks (WDC_WD20EARS) correctly spin down as scheduled except those SAMSUNG drives. What's wrong with them? Why don't you post what the complete hardware setup of your server is and what device you have each drive plugged into. A Syslog might also be helpful for those who can interpret that file. All of them are attached to my ZOTAC - H67ITX-C-E main board (6 SATA ports). Nothing odd to be reported on the syslog.

Sorry if I quote this old post, but I'm having the same issue with two SAMSUNG HD204UI drives I recently added to my configuration. All the other disks (WDC_WD20EARS) correctly spin down as scheduled except those SAMSUNG drives. What's wrong with them?

I tried that. Nothing changed. This is what my ultra.cfg file looks like now: # Generated settings: id="5" #confirm] down="1" stop="1" sleep="1" warn="1" #display] time="%R" date="%c" unit="C" scale="-1" align="right" view="" total="1" spin="1" size="1" snow="0" sleepBtn="1" banner="image" refresh="0" #stats] status="0" access="1" critical="99" warning="90" table="Disks" #check] mode="3" hour="0 0" dotm="1" month="1" day="0" cron="'0 0 1 * * /root/mdcmd check 1> /dev/null 2>&1'" #cache] cache="0" wait="-w" busy="-B" suspend="" shares="" minimum="1" maximum="10" depth="9999" exclude="" include="" other="" #s3sleep] checkHDD="-a" checkTCP="" timeout="30" pingIP="" stopDay="" stopHour="" dhcpRenew="" forceGb="" I must say though, that the schedule works. Only the web interface doesn't reflect the settings set for the parity check.

I tried that. Nothing changed. This is what my ultra.cfg file looks like now: # Generated settings: id="5" #confirm] down="1" stop="1" sleep="1" warn="1" #display] time="%R" date="%c" unit="C" scale="-1" align="right" view="" total="1" spin="1" size="1" snow="0" sleepBtn="1" banner="image" refresh="0" #stats] status="0" access="1" critical="99" warning="90" table="Disks" #check] mode="3" hour="0 0" dotm="1" month="1" day="0" cron="'0 0 1 * * /root/mdcmd check 1> /dev/null 2>&1'" #cache] cache="0" wait="-w" busy="-B" suspend="" shares="" minimum="1" maximum="10" depth="9999" exclude="" include="" other="" #s3sleep] checkHDD="-a" checkTCP="" timeout="30" pingIP="" stopDay="" stopHour="" dhcpRenew="" forceGb=""

Same problem here. Is the feature working?

Plex Media Server, mySQL, APC (but not running ATM). A couple of packages I compiled myself: Transmission, FreePOPs. A script - made by Joe L I think - scheduled for running parity check monthly.

Somebody said it was fixed but I'm seeing it all over my log on 5.0-beta14. Jan 25 01:37:01 Tower crond[1161]: ignoring /var/spool/cron/crontabs/root- (non-existent user) Jan 25 02:37:01 Tower crond[1161]: ignoring /var/spool/cron/crontabs/root- (non-existent user) Jan 25 03:37:01 Tower crond[1161]: ignoring /var/spool/cron/crontabs/root- (non-existent user) Jan 25 04:37:01 Tower crond[1161]: ignoring /var/spool/cron/crontabs/root- (non-existent user) Jan 25 04:40:01 Tower logrotate: ALERT - exited abnormally. Jan 25 05:37:01 Tower crond[1161]: ignoring /var/spool/cron/crontabs/root- (non-existent user) Jan 25 06:37:01 Tower crond[1161]: ignoring /var/spool/cron/crontabs/root- (non-existent user) Jan 25 07:37:01 Tower crond[1161]: ignoring /var/spool/cron/crontabs/root- (non-existent user) Jan 25 08:37:01 Tower crond[1161]: ignoring /var/spool/cron/crontabs/root- (non-existent user) Jan 25 09:37:01 Tower crond[1161]: ignoring /var/spool/cron/crontabs/root- (non-existent user)

Same problem here with 5b14.

I quote every single word. Finally unRAID web guy makes the whole thing feel so new.