nsutherland

It looks like one of the last updates to SWAG changed the behaviour so that it will only read in nginx/site-confs files if they have .conf in the filename, which broke redirection to my radarr/sonarr subdomains (I was getting the default swag homepage instead). I looked at an old backup of my SWAG appdata folder and noticed that in the update, it had replaced my previous 'default' file with 'default.conf' and a sample file. See the log entries below that led me to look into that: **** The following active confs have different version dates than the samples that are shipped. **** **** This may be due to user customization or an update to the samples. **** **** You should compare the following files to the samples in the same folder and update them. **** **** Use the link at the top of the file to view the changelog. **** /config/nginx/nginx.conf /config/nginx/ldap-server.conf /config/nginx/authelia-location.conf /config/nginx/authelia-server.conf /config/nginx/ssl.conf /config/nginx/proxy.conf /config/nginx/site-confs/default.conf I have a subdomain called "services" that points to my radarr/sonarr sites. The filename to redirect to those sites was named 'services' with no filetype extension. The fix for me was simple, and just required that I rename that file to 'services.conf' so that it would read the file, and a restart of the docker to pick up the change.

Thanks CHBMB and sparklyballs, appreciate the support. I updated my docker repository and I've confirmed the graphs are working now. I will await the official 6.4 release of UnRAID and update my docker back to the main repository.

I'm also having the issue in which it's not graphing any data. I've not had any issue accessing the webgui. I've tried deleting the docker and building it from scratch multiple times with no success. I'd be happy to provide any data requested. Here are the logs of it booting up: https://www.linuxserver.io/donations/-------------------------------------GID/UID-------------------------------------User uid: 99User gid: 100-------------------------------------[cont-init.d] 10-adduser: exited 0.[cont-init.d] 30-config: executing...[cont-init.d] 30-config: exited 0.[cont-init.d] done.[services.d] starting services[services.d] done.AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using 172.17.0.2. Set the 'ServerName' directive globally to suppress this message### assuming you are using an fping copy reporting in millisecondsSmokeping version 2.006011 successfully launched.Not entering multiprocess mode for just a single probe.FPing: probing 20 targets with step 300 s and offset 34 s.

Hey guys, So like the rest of us here I bought a bunch of these WD EARS drives. I have 2 x 2TB and 2x 1.5TB EARS drives. I only read about this issue with the sectors about a week ago and I had already written data to them without the compatibility jumper installed. I put the jumper on my drives and got a whole bunch of the errors in the log (READ DMA EXT) upon boot. The box would still boot, it just took a long time for it to display all of these messages before it got to the login prompt. I've fixed 3 of them so far (no more of these errors spamming on boot or in the syslog after the final step below) and I am working on the 4th as we speak. Now when I fixed my disks my array had already been wiped recently so I just ran the preclear script on all of the drives at the same time because I didn't have to worry about saving my data. In some peoples case here I imagine you'll need to do this on one drive at a time. Here is what I did to fix my drives: 1. Run the preclear script on the drive without the jumper placed on 7 and 8. (This may not actually be required but this is a step that I did to fix mine so I won't leave it out). 2. Remove the drive and install the jumper on pins 7 and 8. 3. Re-insert the drive into your box 4. Boot your box (you may have to wait like 10 minutes or so for it to boot due to the errors but it WILL boot eventually so be patient). 5. Run the preclear script on the drive with the jumper on pins 7 and 8. When I had completed the 5th step, the errors had stopped spamming my syslog so this should be something you should check to verify that it has fixed your disks to run with the jumper installed.