SMB Shares inaccessible after update to 5.0.6-0

2

@Mark93 Hello again. And thanks for the report.

Your issue could well be due to a an older database format from 4.1.0 stable or before having been transitioned via a zypper dup etc to a newer Leap and now using the testing channel. Let us know if this correlates to yoru system.

See the following known issue (testing 5.0.6-0 only) that is currently being resolved:

via the linked issue repeated here for ease:

We only try to ensure stable to stable updates and this latest testing channel release has helped to uncovered this new DB compatibility issue ready for the next Stable release. That was we can help to ensure the production update nature we have thus far maintained in the Stable channel. I.e. 4.1.0-0 updates via our how-to to 4.6.1-0. And post the above fix and many others already resolved in testing and to be resolved should help to ensure that 4.6.1-0 updates successfully to 5.1.0-0 when it is released.

The plan is to have a fix for this DB migration issue very shortly. But again this only affects Stables from 4.1.0-0 Leap 15.3 eara that have then been transitioned to latest stable as of a few days ago.

Hang in there and keep an eye on that issue. I’ll update this thread when there is a resolution at hand.

Hope that helps. And it would be good to have your confirmation of a fix on the next testing release, as your report does look a little different. But the indicated issue is my current priority re Rockstor.

1 Like
3

Im in essentially the same boat. Webpage has no problem loading. I can run a balance for instance.

Accessing my Media Share under SMB returns an access denied error on both Windows and Kodi on my amazon fire stick. But Kodi on that same fire stick can see everything if using NFS.

Rockstor install is relatively recent as I installed a new OS drive. The original version of 5 was which ever version introduced tailscale, which ive only briefly messed with.

Its a simple file server so i can wait on the fix with out issue

1 Like
4

@Warbucks Hello again.

@Mark93 's report does look to be different from our ongoing, and currently prioritized database incompatibliity issue. So your likewise may not be the same either. You mention installing a version with Tailscale in. That feature currently only exists in testing and we have no installer that includes that version of testing out yet. Can you confirm that you installed your setup via one of our installers.

@Mark93 Likewise, can you confirm the nature of how you installed this instance of rockstor. Your log would suggest that your system does not have the new back-end we use for storing secrets (cliapp password), but this indicated as a dependency in our rpmbuild spec file. See:

I.e. the password-store package was added as a new dependency.

We also have some setup done within the rpm scriptlets. What do you get, as the root user, at the command line, when you type pass? It should be similar to:

rleap15-5:~ # pass
Password Store
└── python-keyring
    └── rockstor
        ├── CLIENT_SECRET
        ├── SECRET_KEY_FALLBACK
        └── SECRET_KEY

Thanks to you both for the feedback, we are heading towards our next stable release now, within current testing, so such feedback on update failures etc is invaluable. The aim being to resolve all breaking changes that have been made in the earlier stages of the current testing phase.

We plan to have another testing release out due next week, so we can pick up after that one also give it should resolve at least the ongoing DB issue. And as you say @Warbucks, this will not have affected you if you installed with anything after our our early openSUSE based installer based on 15.3 and carrying our 4.1.0-0 rpm. All later installers will have created a 13 format database where-as the 10 format is the once which turned out to be too old for 5.0.6-0’s new Django and Postgres interface library.

Hope that helps. And thanks for your patience here folks. This testing phase has been a little rough on the updates but we have had many long-awaited updates along the way, so should be all good in the end.

1 Like
5

Hello Philip!

If there wasn’t an official installer I must have installed the latest 4 version then id have turned on the testing channels.

I installed tailscale using the instructions referenced in the 5.0 announcements thread

2 Likes
6

Hi @phillxnet
I’m not 100% sure, but I think that I used the Leap 15.4 package V4.5.8-0 from the Download Section and switched then to testing channel.
I remember that I had issues at some point with testing at V5.0.0-5.2.0 at started over with the beforementioned installer package.

The “pass” output looks more or less similar:
rockstor4:~ # pass
Password Store
└── python-keyring
└── rockstor
├── CLIENT_SECRET
├── SECRET_KEY
└── SECRET_KEY_FALLBACK

3 Likes
7

I still have the same issues after updating to 5.0.7-0.
Also I checked some outputs from this post https://forum.rockstor.com/t/after-updating-to-5-0-6-0-web-interface-is-not-accessible-and-network-shares-are-also-not-accessible/9226/48 and it all looks like postgres v13
Except for SMB everything I tested works fine

1 Like
8

@Mark93 Thanks for the feedback.

We have yet to identify the SMB issue and in 5.0.7-0 we only addressed the indicated issues in the release notes. Mainly around the DB format update, if required (i.e. installs derived originally from our 15.3 based installer), and a failure to uninstall the legacy Poetry.

If you could provide any diagnostic info re Samba logs/services etc we can proceed with identifing and fixing that also.

Getting there, bit by bit.

And we do also have @KarstenV pending input on their likely related SMB failure. We have made no changes in that area ourselves, so it may be we have a further adaptation required.

Thanks again for the confirmation, and it’s good to know 5.0.7-0 otherwise installed/worked as intended.

Linking to @KarstenV thread where this likely same failure is outstanding in testing channel:

So this outstanding SMB issue is the focus for our next testing rpm release by the looks of it.

Cheers.

2 Likes
9

Hey, I just started over with a fresh install ( Rockstor-Leap15.4-generic.x86_64-4.5.8-0.install.iso), didn’t really configure anything, updated to v5.0.7-0, set up the necessary config (pool import, smb config) and have exactly the same issue as before with v5.0.6-0 and 5.0.7-0.
The smbd log looks exactly like my previously shared output above.
I will go back to v4.5.8-0 in the meantime… If there is a new release to try, I’ll will upgrade & update asap.

2 Likes
10

Confirmation that I can reproduce that error.
Of note, this seems to only concern our Samba standalone script, and not other standalone scripts such as the st-snapshot from scheduled_tasks.

After adding a simple debugging attempt in src.rockstor.scripts.__init__.py:

import os

os.environ["DJANGO_SETTINGS_MODULE"] = "settings"
import django  # noqa E402
from system.osi import run_command

o, e, rc = run_command("pass")
logger.debug(f"o: {o}; e: {e}, rc: {rc}")
django.setup()

I get the following when trying to access a samba share from my Tumbleweed laptop:

Error: password store is empty. Try "pass init".
Traceback (most recent call last):
  File "/opt/rockstor/.venv/bin/mnt-share", line 3, in <module>
    from scripts.mount_share import mount_share
  File "/opt/rockstor/src/rockstor/scripts/__init__.py", line 17, in <module>
    o, e, rc = run_command("pass")
               ^^^^^^^^^^^^^^^^^^^
  File "/opt/rockstor/src/rockstor/system/osi.py", line 263, in run_command
    raise CommandException(cmd, out, err, rc)
system.exceptions.CommandException: Error running a command. cmd = p a s s. rc = 1. stdout = ['']. stderr = ['Error: password store is empty. Try "pass init".', '']

So, same as the original report above.

As a reminder, this script is triggered as a preexec in our smb.conf. In my case:

[test_share01]
    root preexec = "/opt/rockstor/.venv/bin/mnt-share test_share01"

Running this script manually from the shell works without issue.

My best guess at the moment is that this relates to how Samba calls this root preexec script… Maybe we need to give it some env variables or something like that…
For reference:
https://manpages.opensuse.org/Tumbleweed/samba-client/smb.conf.5.en.html

1 Like
11

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".
1 Like
12

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]
1 Like
13

Do you have to explicitly set the environment variable for the password store?

export PASSWORD_STORE_DIR=<path/to/password storage>
2 Likes
14

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
15

Or maybe we can set it in our mount_share.py script. I’m out of time to test that today, though…

16

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

1 Like
17

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"
1 Like
18

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?

2 Likes
19

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.

2 Likes
20

I took the liberty and created an issue on Github for this:

2 Likes
21

@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 :slight_smile:

2 Likes