Samba shares gone from the UI

Troubleshooting
1

As I was preparing to drop and recreate one of my pools (ref: Pool is read-only - BTRFS - Rockstor Community Forum), I noticed that the Samba shares associated with that pool have all gone bye-bye.

In the first screen shot below, the only Samba share listed is the one associated with my “Pool2”. The list should also include several Samba shares for shares on Pool1, the one that I’m about to rebuild. The shares still exist in my smb.conf and are working fine from client computers. I verified that the smb,conf hasn’t changed recently (based on file date and my knowledge of it).

I’m not too concerned functionally as I’m about ready to rebuild the whole pool anyway, and that will include creating new Samba shares.

My question is this: how does the Rockstor UI know what to display on the Samba page? I assumed it was taking information from smb.conf but that doesn’t seem to be the case.

Thank you.

P.S.: they were listed on the Samba screen a couple of weeks ago when I created the PoolCopy share, so I know this is a fairly recent development.

image
image2723×1731 204 KB

image
image2723×1731 433 KB

smb.comf:
[global]
log level = 3
map to guest = Bad User
cups options = raw
log file = /var/log/samba/log.%m
printcap name = /dev/null
load printers = no

####BEGIN: Rockstor SAMBA GLOBAL CUSTOM####
    workgroup = WORKGROUP
####END: Rockstor SAMBA GLOBAL CUSTOM####

####BEGIN: Rockstor SAMBA CONFIG####
[Videos]
    root preexec = "/opt/rockstor/bin/mnt-share Videos"
    root preexec close = yes
    comment = Samba-Export
    path = /mnt2/Videos
    browseable = yes
    read only = no
    guest ok = no
    admin users = admin Bill Kim 
[Pictures]
    root preexec = "/opt/rockstor/bin/mnt-share Pictures"
    root preexec close = yes
    comment = Samba-Export
    path = /mnt2/Pictures
    browseable = yes
    read only = no
    guest ok = no
    admin users = admin Bill Kim 
[EmbyMedia]
    root preexec = "/opt/rockstor/bin/mnt-share EmbyMedia"
    root preexec close = yes
    comment = Samba-Export
    path = /mnt2/EmbyMedia
    browseable = yes
    read only = no
    guest ok = no
    admin users = admin Bill Kim 
[Home_Media]
    root preexec = "/opt/rockstor/bin/mnt-share Home_Media"
    root preexec close = yes
    comment = Samba-Export
    path = /mnt2/Home_Media
    browseable = yes
    read only = no
    guest ok = no
    admin users = admin Bill Kim 
[PoolCopy]
    root preexec = "/opt/rockstor/bin/mnt-share PoolCopy"
    root preexec close = yes
    comment = Treat as read-only - used for internal backup
    path = /mnt2/PoolCopy
    browseable = yes
    read only = no
    guest ok = no
    admin users = admin Bill Kim 
[Music]
    root preexec = "/opt/rockstor/bin/mnt-share Music"
    root preexec close = yes
    comment = Samba-Export
    path = /mnt2/Music
    browseable = yes
    read only = no
    guest ok = no
    admin users = admin Bill Kim 
    shadow:format = .MusicSnapshot_%Y%m%d%H%M
    shadow:basedir = /mnt2/Music
    shadow:snapdir = ./
    shadow:sort = desc
    shadow:localtime = yes
    vfs objects = shadow_copy2
    veto files = /.MusicSnapshot*/
[Backups]
    root preexec = "/opt/rockstor/bin/mnt-share Backups"
    root preexec close = yes
    comment = Samba-Export
    path = /mnt2/Backups
    browseable = yes
    read only = no
    guest ok = no
    admin users = admin Bill Kim 
    admin users = @Computers
[Documents]
    root preexec = "/opt/rockstor/bin/mnt-share Documents"
    root preexec close = yes
    comment = Samba-Export
    path = /mnt2/Documents
    browseable = yes
    read only = no
    guest ok = no
    admin users = admin Bill Kim 
    shadow:format = .DocumentsSnap_%Y%m%d%H%M
    shadow:basedir = /mnt2/Documents
    shadow:snapdir = ./
    shadow:sort = desc
    shadow:localtime = yes
    vfs objects = shadow_copy2
    veto files = /.DocumentsSnap*/
####END: Rockstor SAMBA CONFIG####
2

@wdc Hello again.
Re:

That’s correct, it’s a top down type thing. I.e. What shares were defined by you through the Web-UI are then stored in the db and asserted in the smb.conf That way when one takes a config backup the info for what was configured is stored in the database ready to be re-asserted to a new install. Not all features are top down, for instance our hdparm ‘settings’ are stored in and read back from the systemd file and have no db component at all. It’s all rather doubled edged and we have tried to do the right thing where we can but parsing an smb file and working backwards to generate the required db each time is also overkill in it’s own right.

The curiosity in your case, as you indicate, is where have the db entries for the samba configs gone in the db. What we have is likely a bug thrown up by the poorly pool experience you had and hopefully in time we weed out such fragility. Elements such as this and getting the right top-down vs bottom-pup balance is a non trivial balancing act that we tend to on an ongoing basis. This came up more recently in our networking actually where we try and play both sides. But ultimately the source of truth should be as clear as possible and the smb file can contain a mount point but the db has to know the share name. These currently are the same, but we also want to be able to re-name the shares and pools. And our shares are mounted by their subvol id for this reason except we currently rely the share name and mount point being identical. There is definitely more work to be done here and elsewhere but our focus currently is getting the v4 out-the-door with as few bugs as possible so we can start to embark on the fairly massive re-write that is required to move us whole-sale to a new Django (our web-db backend) and a new Python. During this move, as has already happened in our CentOS -> openSUSE move, we are very likely to come across and clean up some older kipple that has likely lead to what you have experience here.

Hope that helps, at least for some context. And if you do ever fancy looking deeper into how this all hangs together then take a look at our Community Contributions:
https://rockstor.com/docs/contribute_section.html
doc section and specifically the developer section as we can always use more sets of eyes.

There is a suprising amount of complexity in all this smoke and mirrors and often more than is preferrred but as stated more eyes can always help.

We also have our Technical Wiki entries but alas there is little there currently on the exact nature of our samba stuff. Although @Flox did recently update our AD code and related Wiki entries. But ultimately in-code comments are the best resource for exactly how stuff works right now as the Wiki entries and docs often trail. Although I’ve recently updated our developers subsection of the above contributors so that at least is now completely up to date and proved on a Rockstor 15.3 profile install instance just recently.

As a work around in your case, to return the parity between Web-UI and smb.conf you may either re-create the samba shares, or as you suggest, await your own pending re-do.

Thanks for the report as we haven’t had such a report for some time so we now know at least to keep a carefull eye on this as we poor over the entire code base in our next testing channel release to start very shortly. This time, due to the enormity of the task, we will create a testing branch to allow us to maintain our current to-be Stable v4 release while still being able to make the large code changes necessary in the next testing channel

Lots to do but all good. And thanks again for the report.

2 Likes
3

Great answer (as always) - thank you. Synchronizing two sources is tough. Which one should be the source of truth will come out in the wash at some point. In the meantime, keeping them in sync and accounting for the changes will be a challenge.

1 Like