So I upgraded to samba v8 in hassio and that came with a slew of problems. After spending and embarrising amount of time trying to access the file via \hassio, I found out that samba now uses the hostname or your ip address. No problem I can do that. Accept I don’t know my hostname. So I ssh’ed into hassio to run a few commands and this is what I’m seeing.
Yeah, I can’t actually change it through the UI which is why I found the issues with hassio hassos info. I’ve been having issues for what feels like months with shutdown/reboot. Always get ‘unknown’ errors. Stumbled upon the hassio logs and found the “No manager D-Bus connection available” errors littered throughout it.
Hassio logs show me the same error message. Also the host and hassos info return the same info.
I also upgraded to samba v8 (no clue if this could be the reason though).
The reason samba isn’t working with the hostname is because of this issue. This happened prior to the issue with samba. I’m not sure what the cause is, but it seems like this has happened to a few people. This is clearly a bug but I fear that it will be very hard to reproduce.
Can you connect to Samba using the IP address? I haven’t spotted anywhere in the shell that you could change the samba config. I’d be tempted to backup your configuration as it is, and do a fresh build.
Yes I can. I can’t connect via a hostname because of the root issue in the thread. I’m fairly sure the problem isn’t with samba, but hassos <-> hassio. Samba v8 uses the hostname of the system. That’s null in my case.
are you def on HassOS and not the previous OS (resinOS i think it was, might be wrong) I recently helped someone else who was having loads of issues and that was the issue, the latest supervisor doesnt seem to be happy on the old OS for something.
Your response to the hassio hassos info command is the same as he was getting.
I am using a Pi3b, not the more recent + model. I migrated to hassio around the 0.73 release, but I did a scratch rebuild at 0.81.6 on a fresh sd card, then copied my /config directory back over.
I am also using a Pi3b. I migrated to hassio pretty early, but I don’t remember when (0.6x??).
I was not aware of the change in OS, thanks for pointing that out. I will migrate to HassOS and see if it solves my issue.
You are correct. I spoke with a few developers last night and the culprit is resinOS. If you installed hassio prior to July 2018 (0.73 and below), you are using resinOS with hassio. ResinOS does not contain D-Bus.
@dap35 you actually don’t have hassos, you have ResinOS if you started at v0.73. Updates do not add hassOS, you had to have installed 0.74+ then updated in order to have hassOS.
I started with hassio around 0.61.
So the only way to rectify this problem is to wipe and install from a current version of hassio with hassOS.
Yep, pretty much what needs to be done. It makes sense. I don’t know how I missed the hassos update with that information. At least there is a thread now.
This will be a problem for you if your original Hass.io installation was 0.73 and below. If you initially installed 0.74 and above, you will be fine and this shouldn’t be an issue.
Hassio installations with 0.73 and below contain ResinOS which does not have D-Bus. This will cause issues for Samba V8+ because no hostname can be resolved.
Hassio isntallations with 0.74 and above contain HassOs which will have D-Bus. Your hostname and hassio host info should properly display all information.
@Petro - I’ve done a complete rebuild to move from ResinOS to HassOS which is reflected below . Actually, I did two rebuilds. Once to try out HassOS, where I took a snapshot at ~.73, imaged an old SD card with HassOS, then restored my snapshot. The second was at 81.6, when my old SD card corrupted, and I put in a new card.
Yes, then you shouldn’t have the problem. The take away from this thread should be what I posted above.
HassOS was release in 0.74+ so if you started with 0.74 or above you should be good. If you started with 0.73 and below and upgraded you will have this problem.
it would have been nice if Hassio could have prevented upgrade past a point at which things started to fail. Informing users that to upgrade you would need to backup, install a clean copy and restore and this preventing users from hitting this pain. But i guess you have to expect some pain sometimes on a pre 1.0 product,
I actually missed out on the issue by accident. I started on a Pi2 and after a while wanted to switch it out for a Pi3 I had spare. So I did a clean install on the Pi3 and copied over my snapshot at 0.75.3 so I think i was very lucky