True, but the HIBP timeout failure process should not completely disable SAMBA from being able to be used, which is what I understand the problem to be. Assumptions made in coding decision on connectivity to HIBP may not be valid, or implemented poorly. The HIBP API changed to v3 around the time the HomeAssistant changes were made and there may be a underlying defect that has been lurking all this time. There may be changes to Azure or CloudFlare that are sitting between the user installation and HIBP servers that have brought these to the fore. There may be networking issues on his configuration that have been introduced through a specific combination of add-ons, or configuration choices.
Collecting more information on where the issue is may lead to a solution that does not involve futzing around with the workaround. A graceful degradation rather than an abrupt barrier.
Iām hoping Maikl_Sh follows through with this, even though it may be a careful path so he does not unwittingly disclose his location if he does not wish to, for the benefit of others also.
He may also post some more detailed debug logs which may highlight if there are obsolete versions, dependencies, add-ons such as DuckDNS, PiHole and CloudFlared that may be somehow contributing to the issue.
I ran into a very similar issue yesterday while installing the NUT add-on.
What solved it for me was simply disabling the password check at the supervisor level by commenting out the code that sends the request to the HIBP service. Note that Iām running HA Supervised, so this applies specifically to that setup.
Hereās what I did:
SSH into the host machine.
Enter the supervisor container:
docker exec -it hassio_supervisor bash
Open the password check script:
vi /usr/src/supervisor/supervisor/utils/pwned.py
Find the check_pwned_password function and comment out its contents, leaving only:
return None
Exit the container and restart the supervisor:
ha supervisor restart
(or just reboot the host)
Worked immediately after that.
Keep in mind this works only until the next supervisor update, since the script will be overwritten. Youāll likely need to re-apply the change or create a small script to automate it.
Yes, the problem isnāt widespread and only affects rare cases with limited network access or implicit blocking. Iād like the developers to address this properly. Specifically, simply add an option to the settings to at least temporarily disable online verification.
Weāre adults here, and everyone understands that a simple password is unsafe. If the verification is done at the local system level, thatās fine, but when itās an online service, Iām sorry, but this goes against the entire projectās policy!
Okay, back to business.
The systemās inability to connect to the remote server via API prevents the add-on from saving settings, and consequently, it doesnāt launch.
I provided the application and log errors in the first message.
As for collecting the returned HTTP headers, return code, and debug logs, I donāt know how to do that. If you could provide detailed steps, Iāll try. DNS is set automatically by my ISP, but I tried manually entering 8.8.8.8 and 8.8.4.4 on the router, but it didnāt work.
In general, I donāt see the point in looking for a network denial of access, because the problem will then be solved with workarounds. Changing network settings, changing ISPs, using a proxy or VPN. But the core of the problem lies in the local code of the server itself, which requires online access to function.
Thanks to the person who suggested a solution by editing the code from within Supervisor. I hope the developers will eliminate the need for such solutions in the future.
Your next logical step is to either report it as a bug, or feature request in GitHub, or both.
I suspect the pushback for disabling the HIBP check (feature request) will not have changed, however the ability to continue when there is a network failure (a bug or faulty algorithm) needs urgent attention.
Back to your original problem: Are you able to use Samba now?
Youāre right, itās probably worth filing a bug report. At least it should have a clear and obvious error message, not like now, where the investigation took a ton of time and effort.
Regarding Samba, the issue was resolved thanks to a workaround.
And thank you for trying to figure it out and helping.