Further confirmation: running pass as the preexec script returns the same error:
In smb.conf:
[test_share01]
# root preexec = "/opt/rockstor/.venv/bin/mnt-share test_share01"
root preexec = "pass"
Returns the following error in the samba logs:
Error: password store is empty. Try "pass init".
Using a different script as root preexec in an attempt to check the output of env and gpg --list-secret keys, I get:
LANG=en_US.UTF-8
SYSTEMD_EXEC_PID=15068
INVOCATION_ID=e8fb98302e374dd880eedf5ce9d99c7d
NOTIFY_SOCKET=/run/systemd/notify
SMBDOPTIONS=
PWD=/
JOURNAL_STREAM=8:27930
KRB5CCNAME=/run/samba/krb5cc_samba
NMBDOPTIONS=
PIDFILE=/run/samba/smbd.pid
_NO_WINBINDD=0
SHLVL=2
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
WINBINDOPTIONS=
_=/usr/bin/env
Print gpg secrets:
/root/.gnupg/pubring.kbx
------------------------
sec rsa3072 2024-01-18 [SC] [expires: 2026-01-17]
1BDEF96F988FCC0465A368051B2452E3035471FE
uid [ultimate] rockstor@localhost
ssb rsa3072 2024-01-18 [E]
ls -lah /root/.password-store/python-keyring/rockstor/
total 12K
drwx------ 1 root root 108 Jan 30 16:55 .
drwx------ 1 root root 16 Jan 18 10:24 ..
-rw------- 1 root root 585 Jan 18 10:37 CLIENT_SECRET.gpg
-rw------- 1 root root 551 Jan 30 16:21 SECRET_KEY_FALLBACK.gpg
-rw------- 1 root root 551 Jan 30 16:55 SECRET_KEY.gpg
The latter is similar to what I have when trying to list the keys manually from the shell on this rockstor machine:
rockstable:/opt/rockstor # gpg --list-secret-keys
/root/.gnupg/pubring.kbx
------------------------
sec rsa3072 2024-01-18 [SC] [expires: 2026-01-17]
1BDEF96F988FCC0465A368051B2452E3035471FE
uid [ultimate] rockstor@localhost
ssb rsa3072 2024-01-18 [E]
Do you have to explicitly set the environment variable for the password store?
export PASSWORD_STORE_DIR=<path/to/password storage>
Good question… I’m afraid I’m not up to speed on that one… You are correct that we do set that in build.sh when we first pass init.
To confirm you are onto something… if the script run by root preexec has:
echo "run pass" >> /opt/rockstor/samba-env.txt
PASSWORD_STORE_DIR=/root/.password-store pass >> /opt/rockstor/samba-env.txt
I then see:
run pass
Password Store
└── python-keyring
└── rockstor
├── CLIENT_SECRET
├── SECRET_KEY_FALLBACK
└── SECRET_KEY
Without setting PASSWORD_STORE_DIR that way, I get the same Error: password store is empty. Try "pass init". error.
Unfortunately, setting that in the preexec line seems to upset the way Samba runs this… For instance:
root preexec = "PASSWORD_STORE_DIR=/root/.password-store /opt/rockstor/print_env.sh"
gives me:
sh: PASSWORD_STORE_DIR=/root/.password-store: No such file or directory
Or maybe we can set it in our mount_share.py script. I’m out of time to test that today, though…
samba has the variable substitution %$(envvar), maybe that will work better. Though it seems that adding an import of the environment variable to the script might be the better solution
wouldn’t this also need to be a concatenation of commands (i.e. set env variable and then execute shell script)?
root preexec = "export PASSWORD_STORE_DIR=/root/.password-store && /opt/rockstor/print_env.sh"
I did try that but I was rushed and failed to specify it… my apologies. It failed the same way.
I did try that as follows. In src/rockstor/scripts/__init__.py:
import os
os.environ["DJANGO_SETTINGS_MODULE"] = "settings"
os.environ["PASSWORD_STORE_DIR"] = "/root/.password-store" # new line
import django # noqa E402
django.setup()
/etc/samba/smb.conf remained as produced by Rockstor.
It does seem to fix it as I can connect to that same samba share just fine.
To confirm the need for setting that env variable continuously, I commented out that new line and I could no longer access the Samba share in question, seeing the same 'Error: password store is empty. Try "pass init".' error as before.
@Hooverdan, @phillxnet: I’m not familiar with pass yet when compared to both of you so does that seem like an appropriate fix to you?
Great find!
Considering that this was required in the bootstrap and pre-service to function, I would assume the same will be required for the “new” thread that the samba preexec opens to execute, But, as always, since @phillxnet did the actual implementation across, he will have an opinion on that. If it is, the question will be whether we need to consider explicit definition of the env variable in other places where it doesn’t exist yet.
I took the liberty and created an issue on Github for this:
@Mark93 @Flox @Hooverdan Nice find.
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.
This one was quite the puzzle for a bit there 
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?
Hi @DrHolzer,
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.
@Mark93 @Flox @Hooverdan @Tex1954 @DrHolzer
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.
The fix shown at SMB Shares inaccessible after update to 5.0.6-0 - #18 by Flox fixed things for me. At first shares showed up as \host\exports\share-name instead of \host\share-name but are a reboot it went back to the latter.
Sorry for this not being prettier but i am sending it from my phone.
Just to confirm 5.0.8 fixed the SMB issue for me - thanks for all the hard work guys!
Seconded, working great without having to do anything other than update
YES YES YES!
Werky Verry Gud !!!
Yesterday I updated to version 5.0.8 and now the smb share works again. thanks to everyone who helped. 