madaroda

Latest update to swag appears to have blocked secure access to all my installed dockers. I can access the dockers locally via http://IP address:port, but https://anydocker.mydomain.com asks for a user name and password, none of which are accepted and result in a "403 forbidden" error. Thinking it may be related to a previous htpasswd configuration, I reinstalled swag (copying over only the proxy-conf files I am using and the entire dns-conf directory to the new installation). Still no access. I don't have an .htaccess file in config/nginx. Where do I being to look for a fix? I am stumped.

I've set up Letsencrypt/nginx wildcard on an unraid docker with my own domain. Letsencrypt certificates appear to download fine. I've got sonarr, radarr and a few more subdomains edited and renamed in proxy-confs. Letsencrypt docker opens and ends in "Server ready." Domain.me and anything.domain.me resolve to correct IP. But nothing opens. https://sonarr.domain.me et all are unable to establish a connection to the server, even though sonarr.domain.me pings correctly (to the WAN address). I suspect a config issue, but where?

Terrific work, djoss. I predict this will soon be the go-to certificate manager in unraid. Questions: How would a wildcard certificate be assembled through the proxy manager? How would we go about making the LetsEncrypt cert self-renewing? Edit: Just found that Lets Encrypt wild cards don't work yet. Hope that comes soon.

I moved all plugins to a temporary folder and rebooted. The "/" folder has the following permissions. So it does not seem as if a plugin is masking "/" incorrectly. I will check containers now. Any other ideas?

Here's the zip. tower-diagnostics-20180925-1626.zip

I'd be happy to. I downloaded the Diagnostics from the Tools page, and it is a heavily populated zip file. Which file(s) should I include?

I found the problem. It appears that somewhere along the upgrade process, the permissions for the root folder ("/") were being reset to 700 on every reboot. Adding "chmod 755 /" to the bottom of the /boot/config/file fixed the problem.

I'll keep updating in hopes someone runs into this: Via SSH, I made DOCKER_ENABLED="no" in /boot/config/docker.cfg; and rebooted. Still getting the 500 error on the webgui. The errors reported in /var/log/ngnix/error.log have changed slightly: The very last part (referrer: "http://10.10.10.111/Docker") is new, and came up AFTER I disabled docker altogether. How is that possible? Also I continue to get the following email from my unraid install after reboot: Could this be related? Do I need to add a user "nobody"? Gracias.

UPDATE: I got SSH and webgui up again by reverting to the last saved version of my flash drive (6.3.x). I upgraded to the current version (6.5.x) and SSH continues to run. The WEBGUI is down again, though. I enter my user name and password, and the browser (any of them) now goes to a "500 Internal Server Error --- nginx" page. The content of /var/log/ngnix /error.log is now different, reading: Permissions of /etc/nginx/htpasswd are at 666. Fix?

Disabled dockers as you suggested. Trying webgui through IP address now reports a "502 Bad Gateway - ngnix" page. Still no SSH access. Entering through telnet, here is the contents of /var/log/ngnix /error.log. Also, got this via email: Thanks.

A couple of days ago i added letsencrypt/nginx and organizr2 dockers. I am guessing this was the start of the problems I now have. All of my docker apps are accessible via both internal IP and external https (my own domain). However: I have no access to the unraid webgui. Log files pointed to a permissions error on .htpassword. In following some instructions on fixing that, I rebooted the box. Now I don't even have SSH access with root ("Permission denied" on entering password). I deleted all the password files in /boot/config and rebooted. Only way in is through telnet. Again, all apps work, I just have no (easy) way to configure the system. How do I get my webgui and SSH access back with only telnet at my disposal?

I figured out how to stop a container in the CLI. Stopping Letsencrypt did not fix the issue. I assumed they were related because it happened right after the LE installation. So, here I am, most likely in the wrong thread, and no solution.

Using internal IP will not work (gets the 500 error). Trying hostname (https://unraid.mydomain.com), which in DNS is a C record to mydomain.com (IP set via DDNS on router) just gives me the NGINX "Welcome to our server" page.

I configured the Let's Encrypt (nginx) docker with nzbget, organizr, sonarr, radarr, etc. dockers using my own domain. I can access all of those apps using https (https://nzbget.mydomain.com). But . . . I have lost access to the Unraid GUI. I get a 500 error on the GUI, and a "/etc/nginx/htpasswd" failed (13: Permission denied)" error in /var/log/nginx/error.log. I am trying to enter the GUI locally using http. I can SS=H into unraid, and all the docker apps are accessible. Just not the front end. Advice?

Thanks. It’s what I hoped for. Now off to buy and build.

A year ago, the old motherboard on which unRAID sat stopped working. I did not do anything about it immediately as I wanted to weigh the options, and then procrastination took over. So I still have 8 WD Red 8TB disks sitting idle (two of them are parity), all formatted XFS. I also have two BTRFS-formated SSD cache drives. Now I need to get the stored data back. Is it possible to mount all the devices (HDDs, SSDs and flash drive) in a totally different rig? Do I need to do something special to make the data accessible? Or is there a better way? Thanks

Upgrades have always gone smoothly. But not from 6.3.3 to 6.3.5 (I missed 6.3.4). I am not able to mount unraid shares on my Mac (AFP or SMB), getting the following error: "There are no shares available or you are not allowed to access them on the server. Please contact your system administrator to resolve the problem." Soon after booting into 6.3.5 I got a "SECURITY Information" email with the following: "Tower : May 27 17:24:06 : root : unable to stat /etc/sudoers : Permission denied ; TTY=unknown ; PWD=/ ;" In my log file, the following error appear multiple times: "May 27 17:24:16 Tower root: error: plugins/preclear.disk/Preclear.php: wrong csrf_token" And probably related to my inability to mount, I get the following: "May 27 18:06:09 Tower root: Starting Avahi mDNS/DNS-SD Daemon: /usr/sbin/avahi-daemon -D May 27 18:06:09 Tower avahi-daemon[2790]: Found user 'avahi' (UID 61) and group 'avahi' (GID 214). May 27 18:06:09 Tower avahi-daemon[2790]: Successfully dropped root privileges. May 27 18:06:09 Tower avahi-daemon[2790]: open(/var/run/avahi-daemon//pid): Permission denied May 27 18:06:09 Tower avahi-daemon[2790]: Failed to create PID file: Permission denied May 27 18:06:09 Tower emhttp: shcmd (760): /etc/rc.d/rc.avahidnsconfd start |& logger May 27 18:06:09 Tower root: Starting Avahi mDNS/DNS-SD DNS Server Configuration Daemon: /usr/sbin/avahi-dnsconfd -D May 27 18:06:09 Tower avahi-dnsconfd[2799]: connect(): No such file or directory May 27 18:06:09 Tower avahi-dnsconfd[2799]: Failed to connect to the daemon. This probably means that you May 27 18:06:09 Tower avahi-dnsconfd[2799]: didn't start avahi-daemon before avahi-dnsconfd." This is a bit over my head. Fixable, or should I revert to 6.3.3? Thanks

Thanks johnnie.black. They are unrelated. I had used Chrome to assign the cache drives. I just rebooted and the drives came up unassigned again. I assigned them in Safari, restarted the array, and the cache drives are back on their own. Still am getting those avahi errors though

My apologies if adding to this thread is inappropriate, but I'm running into a similar problem as OP. I'm running 3.3 pro license, with avahi issues. I do have the correct avahi entries in my passwd and shadow files. Instead, I seem to be getting a permissions problem. In my log, this cycle appears every 2-3 minutes: Mar 31 09:21:24 Tower emhttp: shcmd (839): /etc/rc.d/rc.avahidaemon start |& logger Mar 31 09:21:24 Tower root: Starting Avahi mDNS/DNS-SD Daemon: /usr/sbin/avahi-daemon -D Mar 31 09:21:24 Tower avahi-daemon[17320]: Found user 'avahi' (UID 61) and group 'avahi' (GID 214). Mar 31 09:21:24 Tower avahi-daemon[17320]: Successfully dropped root privileges. Mar 31 09:21:24 Tower avahi-daemon[17320]: open(/var/run/avahi-daemon//pid): Permission denied Mar 31 09:21:24 Tower emhttp: shcmd (840): /etc/rc.d/rc.avahidnsconfd start |& logger Mar 31 09:21:24 Tower root: Starting Avahi mDNS/DNS-SD DNS Server Configuration Daemon: /usr/sbin/avahi-dnsconfd -D Mar 31 09:21:24 Tower avahi-dnsconfd[17328]: connect(): No such file or directory Mar 31 09:21:24 Tower avahi-dnsconfd[17328]: didn't start avahi-daemon before [email protected]>@qualcomm.com>@linux.it>@linux.it>@netfilter.org>@trash.net> My pool of two cache drives now appear as unassigned when I boot. I must stop the array, assign the cache drives and restart the array each time. This is probably unrelated to the issue above, but the problems did appear simultaneously so I thought it may be pertinent. Thanks.

I'll answer my own question since I stumbled on to a fix. I ran "chmod g-s /mnt/user/futbol" in the terminal and the warning disappeared.

What a terrific utility. Thank you. I cleared 7 out of 8 warnings/errors. Still have one warning I can't seem to fix: Share futbol has non-standard permissions set The permission on the share is currently set to 2777 (standard permissions are 0777). You may have trouble accessing this share locally and/or over the network due to this issue. You should run the New Permissions tool to fix this issue. (Don't know what these numbers mean? Look HERE NOTE that if this is your appdata share then you will need to manually run the command to fix this. Ask for assistance on the forums. The share is not the appdata share. Running the "New Permissions" tool did not fix the warning. Running "chmod 0777 /mnt/user/futbol" in terminal did not fix the warning. Should I just click "Ignore Warning", or is this somethng fixable?

Thank you johnnie.black and thestewman. Converting the disk to MBR and then using the new preclear beta seems to have done the trick. The 6 TBs are busy preclearing, and I hope to have all in order in, well, a couple of days now.

I wasn't ready to pay the premium either. It was at $269 on Amazon about a week ago, which was only $25 more than the non-pro version. So I pulled the trigger after reading 1-2 posts here of people using it. I could return it and get the 5400 RPM version, but I would like to exhaust all possibilities first. One thing I'd like to rule out (particularly before I return it if I have to): Could the fact that I started a parity sync, got about 12 percent into it and cancelled to do the preclear have caused a problem?

Unfortunately, running preclear with not options (./preclear_disk.sh /dev/sde) results in the same error. I attempted to "zap" the drive using gdisk advanced. Here's the result: Expert command (? for help): z About to wipe out GPT on /dev/sde. Proceed? (Y/N): Y Warning! GPT main header not overwritten! Error is 5 Warning: The kernel is still using the old partition table. The new table will be used at the next reboot. GPT data structures destroyed! You may now partition the disk using fdisk or other utilities. I reboot the box (which seems to take a long time), try preclear again, and get the same error. I am guessing the "Warning! GPT main header not overwritten! Error is 5" may provide a big clue, but I'm not able to find an answer to it.

Thanks thestewman. Did you mean to link to the instructions?