Closed Xitee1 closed 11 months ago
mdegat01
commented
1 year ago Ah yes those characters cannot be used in a mount name since the mount name becomes the file name on disk. I didn't realize \w allowed those in python regex, correcting now with a better validation message. Thanks!
Xitee1
commented
1 year ago those characters cannot be used in a mount name since the mount name becomes the file name
That's really the problem? Because actually you can use them in file names, both, in Windows and Linux. But thanks for fixing the validation. At least then the supervisor can no longer crash by using normal german words :)
Xitee1
commented
1 year ago After looking at the changes you've made I think you misunderstood which field is causing the error. Sorry that I haven't clearly said that. It's the "Remote-Freigabe", not the "Name" (first field). There the check was successful. It didn't allowed me to use umlauts. That's why I replaced the Ü with U in there (see first screenshot). It's the share name itself (defined in my SMB server config) that has an umlaut which causes the error.
json={
"name": "Uberwachungskameras",
"type": "cifs",
"usage": "share",
"server": "nas.local",
"share": "Überwachungskameras", # <-- This is what's failing
"version": "2.0",
},
agners
commented
11 months ago It seems that this causes the D-Bus broker to disconnect the Supervisor :cold_sweat:
hassio_supervisor[421]: 23-10-04 16:19:22 INFO (MainThread) [supervisor.mounts.manager] Creating or updating mount: uber
dbus-broker[136]: Peer :1.82 is being disconnected as it sent a message with an invalid body.
hassio_supervisor[421]: 23-10-04 16:19:22 ERROR (MainThread) [supervisor.mounts.mount] Could not mount uber due to:
homeassistant[421]: 2023-10-04 16:19:22.463 ERROR (MainThread) [homeassistant.components.hassio] Failed to to call /mounts - Could not mount uber due to:To reproduce this there is no SMB server with a share with umlaut needed. It seems that the message we pass to systemd gets declined, before any connection attempt is being made.
This is after clicking connect
agners
commented
11 months ago As @mdegat01 found, the underlying issue is actually in the D-Bus library. It is fixed by https://github.com/Bluetooth-Devices/dbus-fast/pull/261. A bump in Supervisor will follow soon.
agners
commented
11 months ago This is resolved by https://github.com/home-assistant/supervisor/pull/4603.
Describe the issue you are experiencing
I had lots of trouble while trying to connect my network storage. Let me tell what I did: So I tried adding my network storage "Überwachungskameras" to the HA storage. After clicking connect, it would fail:
I really cannot find anything related to this in the logs or it's completely useless. It tells you like "The error is:" with nothing coming after it. When clicking connect again nothing will happen. But this time the connect button is greyed out and the error message will disappear. Even after long waiting nothing happens.
And after that the problems began. So first I tried rebooting the host with the UI. It would not came back up and only show "connetion refused" (luckily it came back after cutting the power). Now, the next day, I tried again after updating core to the latest version. Same issue. Then a supervisor update appeared (from 2023.7.1 to 2023.8.1) on which I clicked install. First trough the UI (where it would be stuck for ~2 hours) and later with the command "ha supervisor update" where it told me finally something useful after around one hour of waiting:
Post “[http://supervisor/supervisor/update 10](http://supervisor/supervisor/update)”: context deadline exceeded (Client.Timeout exceeded while awaiting headers)So after a lot of googling I found this thread. I executed the manual update script and finally the update was finished.. and I was able again to add other network storages. After trying it again with the "Überachungskameras" it failed again and the supervisor kind of crashed like before.
After some testing it clearly is the Umlaut (Ä, Ö, Ü) which is causing the issue. In the name it is actually checking them. But not in the share name.
I know that the problem also is that the frontend is allowing these characters and thus "cause" the issue but I reported it here because I think it still is more supervisor related because a wrong character in my opinion should not crash the whole supervisor service. There needs to be better error handeling or timeouts. Or at best we get it to work with german umlauts. For me HA so far is the only thing which is causing problems with them. Let me know if this is the wrong place and I should report the issue somewhere else.
What type of installation are you running?
Home Assistant OS
Which operating system are you running on?
Home Assistant Operating System
Steps to reproduce the issue
Anything in the Supervisor logs that might be useful for us?
System Health information
Nothing available
Supervisor diagnostics
No response
Additional information
No response