I had completely overlooked this ramification to our new secrets managment added in 5.0.6-0 as a small part of an extensive update of our Python dependencies:
And yes, there is a definite requirement for us to declare the environmental variable that guides pass to it’s pre-configured secrets store.
Excellent exposition here folks. But I’ve yet to fully digest all this as I’m currently working in another area currently. Lets try to have a fix ready for our next rpm release.
I am also interested. Since installing 5.06.0 then updating to 5.07.0 I can no longer access my setup from my Windows 11,10,7 systems no matter what I try.
I can now connect to my Samba shares but they all show as \host\export\share_name instead of \host\share_name. A short term frustration I can overcome to be sure. Is anyone else experiencing this inconvenience?
Thanks for reporting this. At first glance, what you described seems to fit the failing script detailed above so I think we are seeing the same root cause here.
Just a quick update, in the issue specific branch of by current draft pull request, associated with the GitHub issue raised by @Hooverdan, I’m pretty sure I’m on the home run to a proper fix for at least the reported keyring.errors.NoKeyringError related to an unset PASSWORD_STORE_DIR when samba tries to run the preexec for each export.
And under @Hooverdan’s in-issue advisement , and given we are still in testing phase here, I’ve also centralised our problematic secrets store env var. An overdue arrangement that seems to have found it’s time be be resolved.
Hope that helps, at least by way of a progress update. Once all sorted and provisionally tested, I’ll build and release our next testing channel updates rpm. This should retroactively fix all current testing rpm installs in this regard.
