5 hours ago, Squid said:

7 hours ago, rjorgenson said:

I'm seeing this same behavior. Fix Common Problems reports it's unable to communicate with github.com but all internet connectivity, including to github.com works from the host.

At what point are you seeing this? Only at the initial array start or on all subsequent scans?

I continue to see the error if I rescan. I also haven't restarted my array since before this started. It showed up on my weekly scan on Sunday morning(~22 hours ago), and was not present the week before.

6 hours ago, Squid said:

7 hours ago, rjorgenson said:

I'm seeing this same behavior. Fix Common Problems reports it's unable to communicate with github.com but all internet connectivity, including to github.com works from the host.

At what point are you seeing this? Only at the initial array start or on all subsequent scans?

I had some time and dug into this a little more. I saw in the code that it's running a ping check against github.com which is indeed failing from my unRAID machine. It does not fail from other systems on my network though and my unRAID box is still able to connect to github.com, just not over ICMP.

 

root@mnemos:~/usr/local/emhttp/plugins/fix.common.problems# ping -c 2 github.com
PING github.com (18.194.104.89) 56(84) bytes of data.

--- github.com ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1005ms

root@mnemos:~/usr/local/emhttp/plugins/fix.common.problems# telnet github.com 80
Trying 18.194.104.89...
Connected to github.com.
Escape character is '^]'.
^]

telnet> quit
Connection closed.
root@mnemos:~/usr/local/emhttp/plugins/fix.common.problems#

I don't see anything in iptables that would be blocking this(though I'm not the best with iptables so I could be missing something), and I am able to ping other public sites such as google and yahoo from the unraid host.

Edited December 11, 20178 yr by rjorgenson

On 12/10/2017 at 10:51 PM, rjorgenson said:

I had some time and dug into this a little more. I saw in the code that it's running a ping check against github.com which is indeed failing from my unRAID machine. It does not fail from other systems on my network though and my unRAID box is still able to connect to github.com, just not over ICMP.

 

root@mnemos:~/usr/local/emhttp/plugins/fix.common.problems# ping -c 2 github.com
PING github.com (18.194.104.89) 56(84) bytes of data.

--- github.com ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1005ms

root@mnemos:~/usr/local/emhttp/plugins/fix.common.problems# telnet github.com 80
Trying 18.194.104.89...
Connected to github.com.
Escape character is '^]'.
^]

telnet> quit
Connection closed.
root@mnemos:~/usr/local/emhttp/plugins/fix.common.problems#

I don't see anything in iptables that would be blocking this(though I'm not the best with iptables so I could be missing something), and I am able to ping other public sites such as google and yahoo from the unraid host.

For what it's worth, I just updated Fix Common Problems which caused it to re-run the scan and it did not find this issue again. Confirmed on the command line I was now able to ping github from this system. I'm not sure what changed.

14 minutes ago, rjorgenson said:

I'm not sure what changed.

Nothing on my end.

This is a new one on me-

Event: Fix Common Problems
Subject: Warnings have been found with your server.
Description: Investigate at Settings / User Utilities / Fix Common Problems
Importance: warning

**** Template URL for docker application binhex-delugevpn is missing. ****   **** Template URL for docker application binhex-radarr is missing. ****   **** Template URL for docker application binhex-sonarr is missing. ****   

I'm not exactly sure what this means or how to fix it. I notice they are all my binhex dockers, so is this something on his end?

 

@binhex and I were wondering how long it would take.

 

Go to FCP, and there's a "Fix" button next to all of those warnings.  He made changes to the templates to allow any future template changes to take effect with future updates.

Hey, I’m a weiner winner. ?

I'm also having issues contacting GitHub.com and my rescans are just freezing up and not completing. I am getting the error even after updating the CA Fix common problems plugin.

Unable to communicate with GitHub.com. 

I can successfully ping GitHub from other network machines but not my unraid rig

 

In fact when I go to the plugins tab it just churns and gets stuck at Please wait, retrieving and updating plugin information ...

 

Jan 2 09:01:31 Tower nginx: 2018/01/02 09:01:31 [error] 10227#10227: *350108 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 192.168.2.101, server: , request: "POST /plugins/fix.common.problems/include/fixExec.php HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock", host: "192.168.2.10", referrer: "http://192.168.2.10/Settings/FixProblems"

 

EDIT: fixed, it was my pfsense firewall rule

Edited January 2, 20188 yr by ffhelllskjdje

Really love the work you've done on this plugin, always one of the first I install on a new UnRaid Install.

 

Now I have a small request to make.  I notice that it runs the basic scan on every Reboot of the system.  The UnRaid box doesn't get an internet access until a short while after booting so every time I reboot, I get the error notification:

 

Unable to communicate with GitHub.com

 

Would it be possible to add a delay setting for the Boot-up Scan?  This is the only error I get and as soon as I get in to the interface and re-ruin the scan, the error goes away because UnRaid has established a connection to the internet by that point.

On 1/5/2018 at 9:15 AM, axipher said:

Would it be possible to add a delay setting for the Boot-up Scan? 

Startup scans as of today's update are now delayed by 10 minutes, and run in the background

I'm receiving an error that my "Default docker appdata location is not a cache-only share" what's strange is I wasn't getting this error before.  I'm not using the appdata share, instead I'm using a share called Docker, that is set to cache-only, and is set as the "Default appdata storage location" within Docker advanced settings.  I've ignored the error for now, but find it odd that this wasn't an issue previously.

Edited January 10, 20188 yr by sureguy

Show me your diagnostics

1 minute ago, Squid said:

Show me your diagnostics

 

phatstore-diagnostics-20180109-2208.zip

ok.  I see the problem.  FCP has been assuming that the default location refers directly to a share, and not to a folder within a share.  In this case, it appears that you've also got an appdata share which is set as use cache "no", and since your subfolder off of the Docker share also happens to be the same name as a share it's getting looking at the share settings for appdata, and not Docker.

 

You must've just recently made some changes that triggered this, but I'll update FCP to account for it as there is nothing wrong with your docker settings.

I don't have an appdata share - I've attached a picture of my shares - unless the "CA Appdata Backup" share is confusing things

Edited January 10, 20188 yr by sureguy

1 minute ago, sureguy said:

I don't have an appdata share

Well, you did at some point (and recently or added the subfolder to the docker config recently)

 

/boot/config/shares/appdata.cfg exists and is set as use cache no.

 

Nevertheless, the issue is in FCP, and will probably get fixed tomorrow.  That test hasn't changed at all in probably over a year.

4 minutes ago, Squid said:

Well, you did at some point (and recently or added the subfolder to the docker config recently)

 

/boot/config/shares/appdata.cfg exists and is set as use cache no.

 

Nevertheless, the issue is in FCP, and will probably get fixed tomorrow.  That test hasn't changed at all in probably over a year.

 

Ahh - I did fat finger something when setting up a docker, and then just removed the folder via ssh.  Sorry for the confusion. 

 

Removing the appdata.cfg fixed the issue.

 

Thanks for the help and your work.

Edited January 10, 20188 yr by sureguy

On 1/9/2018 at 10:35 PM, sureguy said:

 

Ahh - I did fat finger something when setting up a docker, and then just removed the folder via ssh.  Sorry for the confusion. 

 

Removing the appdata.cfg fixed the issue.

 

Thanks for the help and your work.

ok  This is now fixed on today's update.  It will now find the proper share and check it.  Also fixed a couple of other similar edge cases if storing appdata on a UD mounted device.

Today, I got very surprised to see The Fix Common Problems plugin giving me the warning below:

 

The statistics plugin is installed, but the preclear disk plugin is not installed. There is no reason to have statistics installed but not Preclear. It is recommended to uninstall statistics here [followed by a button to access the plugins page]

 

Really? My initial reaction was of the WTF?? kind. Those are two very nice and useful plugins, but they have nothing to do with one another. Can we honestly state that there is "no reason to have Statistics installed but not Preclear"? Really?

 

I don't plan to add drives anytime soon. And if I do, I'll simply add them to the array. I do not necessarily *need* to format them outside. Plus, the Stats have nothing to do with Preclear.

 

Again, both are nice, but I feel that this kind of "forced" recommendation (what the heck, recommend uninstalling something I use??) is counterproductive and does not help people in doubt. It just throws in more confusion and disinformation. This has nothing to do as a warning.

37 minutes ago, denishay said:

Plus, the Stats have nothing to do with Preclear.

Slow your roll.

 

One of two things happened here. Either @Squid made a mistake and picked up the wrong statistics plugin, in which case a fix will be forthcoming,

or, and this is more likely, the statistics plugin referenced was installed by, and ONLY used, by the preclear plugin to submit preclear statistics to the cloud for mass analysis of preclear data, and preclear data ONLY. In which case, yes, the Stats have something to do with Preclear.

 

Are you SURE you don't have the preclear stats plugin?

I'm talking about statistics sender which is part of preclear, not Dynamix Stats which has nothing to do with it.    And FCP is checking for statistics sender, not dynamix stats installed without preclear.  I guess that I can make the wording clearer, but in the installed Plugins section, it is named "Statistics"

 

My point is that stats sender installed without preclear installed is 100% pointless and while at best may be benign and cause no trouble, and at worst its another plugin installed which may under certain circumstances cause issues.  Either way, having a completely unused plugin installed (if preclear is not installed, which is the only way the warning trips) doesn't make any sense.

Edited January 18, 20188 yr by Squid

And as an aside, I do believe that with any test in FCP I am more than fair.  While ultimately every single test boils down to my opinion on the matter, someone has to make the determination.  And my track record with FCP does show that when I am in error about such and such test I do adjust accordingly.

23 hours ago, Squid said:

I'm talking about statistics sender which is part of preclear, not Dynamix Stats which has nothing to do with it. 

 

Ahh... that makes a lot more sense now !

 

thanks!

 

Quote

Either way, having a completely unused plugin installed (if preclear is not installed, which is the only way the warning trips) doesn't make any sense.

 

Indeed. Probably I got confused, but probably the message wasn't extremely clear either  Who knows…

 

 

I inquired about some errors last June, and never followed up on it again, but am now hoping to get them resolved.  I posted in the binhex-delugevpn thread, since they refer to that docker, but wanted to ask here also, since this is the application throwing the errors.

 

errors refer to host ports 58846 and 58946

 

I tried adding host port 58946 to the docker, and re-ran the extended test, but still show same errors.

 

also, they show under the Ignored Errors & Warnings header and also (slightly differently) under the All Ignored Errors & Warnings header.  I honestly don't know what the difference is between the two sections, why show some, then all right after?  Why not just show all?

11 minutes ago, JustinChase said:

58846 and 58946

58846 vs 58946 refer to setting up @binhex's VPN apps in either VPN mode or normal mode AFAIK.  You could term it a false positive, since that's how it's suggested to set up the apps (by removing one of them).  It's been previously suggested to me to put in a special test for binhex templates and I have elected not to because IMHO if the ports are listed in the template but not on your installed app, then it is an error / warning.  That, and its easy to ignore  (IE: don't want to go down the road of having checks for individual apps where its perfectly acceptable and even desired in some cases to set it up as such - I just don't have that much time on my hands)

 

 

11 minutes ago, JustinChase said:

re-ran the extended test

The extended tests are basically full file system checks - permissions, duplicate filenames.  What you wanted to hit was "Re-Scan"

 

 

11 minutes ago, JustinChase said:

Ignored Errors & Warnings

These are the warnings / errors that are ignored that are found in the last scan

 

11 minutes ago, JustinChase said:

All Ignored Errors & Warnings

This is the list of ALL errors / warning that you've ignored, regardless of whether its found on the last scan or not.  It's there to let you re-monitor an error that you've previously ignored, it isn't currently present, but you want to be alerted for should it happen again.

Edited January 19, 20188 yr by Squid