[Plugin] CA Fix Common Problems

[Juniper]

thank you both very much for your help 🙂

 

 

[itimpi]

13 hours ago, Juniper said:

I now have uninstalled the deprecated rutorrent docker app and deleted the directories it had created under /mnt/user. After rebooting the server FixCommonProblems no longer complained about the "user" share.

 

But the question remains:  When I install a different bittorrent docker app, I will also have to reference the directory where the shares are located in, and that is /mnt/user. Will I then get the same problem again with having a "user" share?

 

Should I rather make a new directory in /mnt which then points to the same where "user" and "user0" point to? If yes, how would I do that?

 

Thank you so much.

You might want to read this part of the online documentation that describes how User Shares work and how they relate to paths at the linux level.

 

It sounds as if you may have managed to create a folder called ‘user’ on one of your drives which is what FCP is complaining about.    This would most likely happen by setting up an incorrect mapping in a docker container.

[Drikani]

On 7/22/2021 at 3:45 PM, Linguafoeda said:

Is there a way to disable Fix Common Problems from checking for updates that are already queue'd to be installed? I keep getting notifications of "x docker app has an update available for it" and want to minimize those discord alerts since it will get auto-updated at 5am.

 

Is there anywhere else to tweak exact notifications that Fix Common Problems sends out?

 

This one would be great to know.

I manage all my docker containers with portainer and watchtower and do not need those notifications and errors popping up all the time.

Is there any way for me to disable this on module?

All the other checks I still want to be able to monitor and be notified about.

On the unraid docker tab it also shows me that there are updates available for my containers even though there are none and it really bugs me out.

I don't want unraid to manage those things for that I have portainer with a much better UI...

[TeroS]

Possible bug:

Just updated to 2022.01.01 and got this:

Quote

There is no DNS entry for server.domain, recommend setting your TLD to local or adding a DNS entry for server.domain. Fix it here:

However this is not true, in settings I have a "domain.com" set and my dns-server also resolves "server.domain.com" correctly. Also this error have not been present before since it's obviously not an error.

[Squid]

1 hour ago, TeroS said:

There is no DNS entry for server.domain

 

1 hour ago, TeroS said:

in settings I have a "domain.com"

Bug due to the .com  Try the update

 

1 hour ago, TeroS said:

Also this error have not been present before since it's obviously not an error

New test as of today.  Also like everything else in FCP (especially warnings), there is no black and white, but rather all of the tests are "grey areas" and guidelines.  If everything works then feel free to ignore.

[TeroS]

Quote

Bug due to the .com  Try the update

The 2022.01.01a fixes this false report. Thanks for quick work!

[aburgesser]

Are you still open to feedback about the severity of the self update check? I really did not need the adrenaline rush of seeing an error of the app being out of date. I don't think the plugin should consider itself any different from other plugins for out of date notices. Over escalating errors is a good way to have that issue type set for ignored. I find this unfortunate because now I will only notice FCP is out of date when I go to update another plugin.

 

In my opinion, the only time an out of date app should result in an error is if it either leaves a known vulnerability open or has a known data risk. Both items are more nuanced to identify than I expect the app to be able to.

[Squid]

The difference between FCP and other plugins is that you're not relying upon other plugins to inform you of issues with the server.  So with that FCP not updating via the Auto Update plugin automatically winds up flagging itself being out of date on your scheduled scans as an error, because it is paramount that 

 

- Bug fixes on the tests get fixed

- Any new tests which may potentially impact you are correctly flagged.

 

The alternative is that FCP always downloads an updated list whenever it runs a scan.  IE: It updates itself automatically

 

And besides, you can always hit ignore on that error and you won't be bugged anymore.

 

On 1/3/2022 at 12:16 AM, aburgesser said:

out of date app should result in an error is if it either leaves a known vulnerability open or has a known data risk.

That scenario (severe risk) is actually handled via Community Applications itself (opt-in), and the warnings that it puts out are sure to catch your attention.  CA handles that because even though FCP is quite commonly installed it still has nowhere near the install base that CA has.

[NeoID]

On 12/30/2021 at 4:32 PM, Drikani said:

 

This one would be great to know.

I manage all my docker containers with portainer and watchtower and do not need those notifications and errors popping up all the time.

Is there any way for me to disable this on module?

All the other checks I still want to be able to monitor and be notified about.

On the unraid docker tab it also shows me that there are updates available for my containers even though there are none and it really bugs me out.

I don't want unraid to manage those things for that I have portainer with a much better UI...

I'm having the same issue. I managed to hide the visual elements and you can read about it here: https://www.reddit.com/r/unRAID/comments/rlbubo/hide_update_info_from_the_docker_page_when_using/

But I have not found any way of disabling the notifications only for docker containers. Is there a way to do so? I have my own python-script to update all on one go and the notification doesn't seem to go away even though the container has been updated. I have 50+ docker containers and I'm not really into rewriting them as I prefer portability. I like FCP, would it be possible to ignore all container updates somehow so I don't have to ignore them on a per-container basis?

Edited January 7, 2022 by NeoID

[Mantene]

Getting:
 

Quote

The DNS entry for 'servername.domain.me' resolves to xxx.xxx.xxx.xxx, you should ensure that it resolves to Array.

But it DOES resolve to the array. I am using an external DNS server. It points to exactly where it is supposed to. Am I missing something? (yes, I changed the TLD and IP)

I just updated the plugin, for what it is worth.

[matty2k]

I think since 2022.01.01 my TLD fritz.box is reported in common problems.

fritz.box in Germany is a wide spread TLD used by AVM Fritz!Box.

Kind regards

[ljm42]

31 minutes ago, Mantene said:

Getting:
 

But it DOES resolve to the array. I am using an external DNS server. It points to exactly where it is supposed to. Am I missing something? (yes, I changed the TLD and IP)

I just updated the plugin, for what it is worth.

 

Would you please DM me the url it mentions as well as the IP it resolves to. And your diagnostics. Thanks!

[ljm42]

13 minutes ago, matty2k said:

I think since 2022.01.01 my TLD fritz.box is reported in common problems.

fritz.box in Germany is a wide spread TLD used by AVM Fritz!Box.

Kind regards

 

What is the exact error message? You can DM it to me if it contains private info. 

[matty2k]

It is exactly:

Invalid TLD

There is no DNS entry for 'NASA.fritz.box', recommend setting your TLD to 'local' or adding a DNS entry for 'NASA.fritz.box'. Fix it here:

 

I am also using pihole as main DNS server and all listed devices are xxx.fritz.box

 

BR

[ljm42]

2 hours ago, matty2k said:

It is exactly:

Invalid TLD

There is no DNS entry for 'NASA.fritz.box', recommend setting your TLD to 'local' or adding a DNS entry for 'NASA.fritz.box'. Fix it here:

 

I am also using pihole as main DNS server and all listed devices are xxx.fritz.box

 

BR

 

OK, so your servername (on Settings -> Identification) is "NASA" and your Local TLD (On Settings -> Management Access) is "fritz.box". Put those together and you are telling Unraid that its hostname is NASA.fritz.box.

 

This FCP warning is saying that when Unraid does a DNS lookup for NASA.fritz.box, it does not get an IP address back.

 

If your client computers are able to resolve NASA.fritz.box, then that means your client computers are using a different DNS resolver than the server, which is actually pretty common. We often tell people not to point their Unraid box at a pihole.

 

The point of this check is to help people who have completely wrong Local TLDs, but it inadvertently caught you because (presumably) the server is using a different DNS resolver than your clients. If your clients are able to resolve NASA.fritz.box fine then you are probably fine and can ignore this one. I need to think about a different way to word the warning.

 

 

@Mantene is this your situation too? the url works from the clients but not the server because the server is using a different DNS resolver than the clients?

[sonofdbn]

I'm on FCP 2022.01.06 and I started getting this error message labelled "Invalid Certificate 1":

"Your Tower_unraid_bundle.pem certificate is for 'Tower' but your system's hostname is 'Tower.local'. Either adjust the system name and local TLD to match the certificate, or get a certificate that matches your settings."

 

I haven't received this error before and haven't done anything with certificates for years, so I suspect this is the result of a new check that FCP is doing. Should I be doing something to fix this, and if so what? I don't know much about certificates and don't want to bork the system.

[Squid]

Waiting for @ljm42 to respond.  I know how I'd fix it, but want the "official" method first.

 

These are indeed new tests, and designed to get your system properly secured and with the ability to properly communicate with other items on the local network.  It actually all started due to a lucky misconfiguration on my part where my SMB Unassigned Devices mounts that had worked for years suddenly failed with a Windows 11 update last month.

[ljm42]

8 hours ago, sonofdbn said:

I'm on FCP 2022.01.06 and I started getting this error message labelled "Invalid Certificate 1":

"Your Tower_unraid_bundle.pem certificate is for 'Tower' but your system's hostname is 'Tower.local'. Either adjust the system name and local TLD to match the certificate, or get a certificate that matches your settings."

 

I haven't received this error before and haven't done anything with certificates for years, so I suspect this is the result of a new check that FCP is doing. Should I be doing something to fix this, and if so what? I don't know much about certificates and don't want to bork the system.

 

On Settings -> Management Access, what is "Use SSL/TLS" set to ?  I'll assume it is set to "Yes"

 

It also looks like your "Local TLD" setting is "local", which is good.

 

This means if the system ever generates a URL to itself (particularly in Unraid 6.10) it will use https://tower.local . We want to make sure that url works correctly before you upgrade to 6.10.

 

I would recommend deleting your certificate and letting Unraid generate a new one.

 

Probably the easiest way to do that is go to Settings -> Management Access and set "Use SSL/TLS" to "No" (this will temporarily change your url to http://tower.local or http://ipaddress and you'll need to sign in again). 

 

Then open a web terminal and type:
  rm /boot/config/ssl/certs/*.pem
  exit

 

Then go back to the web gui and change "Use SSL/TLS" back to "Yes". This will generate a new self-signed certificate that works on both https://tower.local and https://tower 

[MrChip]

4 hours ago, ljm42 said:

 

On Settings -> Management Access, what is "Use SSL/TLS" set to ?  I'll assume it is set to "Yes"

 

It also looks like your "Local TLD" setting is "local", which is good.

 

This means if the system ever generates a URL to itself (particularly in Unraid 6.10) it will use https://tower.local . We want to make sure that url works correctly before you upgrade to 6.10.

 

I would recommend deleting your certificate and letting Unraid generate a new one.

 

Probably the easiest way to do that is go to Settings -> Management Access and set "Use SSL/TLS" to "No" (this will temporarily change your url to http://tower.local or http://ipaddress and you'll need to sign in again). 

 

Then open a web terminal and type:
  rm /boot/config/ssl/certs/*.pem
  exit

 

Then go back to the web gui and change "Use SSL/TLS" back to "Yes". This will generate a new self-signed certificate that works on both https://tower.local and https://tower 

 

I'm also getting the Invalid Certificate error from FCP. I don't use self-signed certs but use use Lets Encrypt certs. My home network is all based on a local domain name local.mydomain.tld, and my certs are for myserver.local.mydomain.tld.

 

In settings I had Local TLD set to local, which doesn't match the certificate, but everything was working fine, so I missed this. I changed Local TLD to local.mydomain.tld . 

 

I feel that change should work, but I'd like to confirm that there won't be an issue going to 6.10. Perhaps @ljm42 can comment on this?

 

After changing the Local TLD, I now get the same FCP error, but this time it's due to a case mismatch - the certificate uses all lower case domain name, but my Server Name setting uses an upper case letter. I'll change the server name setting, but as host and domain names are case insensitive, I suggest that FCP do a case insensitive match.

 

Edited January 8, 2022 by MrChip

[Niklas]

9 minutes ago, MrChip said:

After changing the Local TLD, I now get the same FCP error, but this time it's due to a case mismatch - the certificate uses all lower case domain name, but my Server Name setting uses an upper case letter. I'll change the server name setting, but as host and domain names are case insensitive, I suggest that FCP do a case insensitive match.

 

Got the same warning. Invalid Certificate 1. Server.lan vs server.lan. 

Edited January 8, 2022 by Niklas

[Squid]

Fair enough.  You're correct that TLD is case insensitive

[ljm42]

11 minutes ago, MrChip said:

In settings I had Local TLD set to local, which doesn't match the certificate, but everything was working fine, so I missed this. I changed Local TLD to local.mydomain.tld . 

 

I feel that change should work, but I'd like to confirm that there won't be an issue going to 6.10. Perhaps @ljm42 can comment on this?

 

Perfect, yes that is one of the problems this test was intending to catch. Unraid (particularly 6.10) uses  servername.LocalTLD to generate links to itself so if you have a custom cert then the LocalTLD needs to match the cert.

 

12 minutes ago, MrChip said:

After changing the Local TLD, I now get the same FCP error, but this time it's due to a case mismatch - the certificate uses all lower case domain name, but my Server Name setting uses an upper case letter. I'll change the server name setting, but as host and domain names are case insensitive, I suggest that FCP do a case insensitive match.

 

5 minutes ago, Niklas said:

Got the same warning. Server.lan vs server.lan. 

 

Thanks for reporting! we can make this match case insensitive

 

[sonofdbn]

10 hours ago, ljm42 said:

 

On Settings -> Management Access, what is "Use SSL/TLS" set to ?  I'll assume it is set to "Yes"

 

It also looks like your "Local TLD" setting is "local", which is good.

 

This means if the system ever generates a URL to itself (particularly in Unraid 6.10) it will use https://tower.local . We want to make sure that url works correctly before you upgrade to 6.10.

 

I would recommend deleting your certificate and letting Unraid generate a new one.

 

Probably the easiest way to do that is go to Settings -> Management Access and set "Use SSL/TLS" to "No" (this will temporarily change your url to http://tower.local or http://ipaddress and you'll need to sign in again). 

 

Then open a web terminal and type:
  rm /boot/config/ssl/certs/*.pem
  exit

 

Then go back to the web gui and change "Use SSL/TLS" back to "Yes". This will generate a new self-signed certificate that works on both https://tower.local and https://tower 

 

"Use SSL/TLS" was set to "Auto". "Local TLD" setting was indeed "local".

 

I followed the instructions, but I end up with an unsecure connection to the server. In Chrome I get a warning "This server could not prove that it is tower.local; its security certificate is not trusted by your computer's operating system. This may be caused by a misconfiguration or an attacker intercepting your connection."

 

If I look at the Certificate I see this: "This CA Root certificate is not trusted. To enable trust, install this certificate in the Trusted Root Certification Authorities store."

 

I realise that actually in the past I always had an insecure connection (I don't access the Web GUI other than from the local network). If I set "Use SSL/TLS" back to "Auto" I don't get a warning in the browser - but it's still an insecure connection. Just didn't think about it at the time.

 

Sorry if it's not quite on-topic, but how do I set up a secure connection? I can't provision the Certificate as I get a "DNS rebinding protection enabled" error. I'm running the Pi-hole container, so I wonder if there's something I need to do there.

 

 

[ljm42]

1 hour ago, sonofdbn said:

I followed the instructions, but I end up with an unsecure connection to the server. In Chrome I get a warning "This server could not prove that it is tower.local; its security certificate is not trusted by your computer's operating system. This may be caused by a misconfiguration or an attacker intercepting your connection."

 

If I look at the Certificate I see this: "This CA Root certificate is not trusted. To enable trust, install this certificate in the Trusted Root Certification Authorities store."

 

I realise that actually in the past I always had an insecure connection (I don't access the Web GUI other than from the local network). If I set "Use SSL/TLS" back to "Auto" I don't get a warning in the browser - but it's still an insecure connection. Just didn't think about it at the time.

 

Sorry if it's not quite on-topic, but how do I set up a secure connection? I can't provision the Certificate as I get a "DNS rebinding protection enabled" error. I'm running the Pi-hole container, so I wonder if there's something I need to do there.

 

Any time you use a self-signed certificate the browser will complain that it is insecure. This is because the server itself signed the certificate and not a trusted certificate authority like Let's Encrypt. If your bank were doing this it would be a problem, but since this is for your personal use and you trust your own server it isn't really a problem.

 

If you want to use a fully legit certificate instead, you'll need to figure out how to disable DNS rebinding protection on your network. This could be enforced by your ISP, your DNS server, your pihole, or your router. You'll need to spend some quality time with Google to figure out how to disable it on your network  

[sonofdbn]

Thanks. I had already done some Googling and couldn't find anything that explains enough down at my level. Bottom line is: will there be any problems with 6.10 if I just leave things as they are?