Shares not visible after update to RS 4.1 on HP Proliant Microserver N54L Gen7

Support
1

Brief description of the problem

Following a struggle, the system is updated to V4.1.

However the shares are not visible to Windows File Explorer on the network.

Any help diagnosing this would be greatly appreciated.

The log of the switch to V4.1 is below. A number of the issues listed have been mentioned in other posts.

I’ve also listed at the end some things that I think could be improved in the documentation and installer.

Log of Switch to V4

• Creating installer. The recommended (Windows) software is Rawrite32. This software doesn’t look for ISO files by default, and when used gave me a USB drive that failed to boot.
• I used balenaEtcher which provides a portable installation and looks for ISO files. This wrote a bootable image over a FAT32 formatted USB with no problems. I think this should be recommended for creating installation media using Windows
• The resulting USB booted on the N54L but the system lost touch with the screen. CTRL+ALT+DEL worked to abandon the boot.
• Following suggestions on other threads about installing Rockstor V4 on AMD processors, I added nomodeset to the kernel parameters using the grub editor (entered by pressing e before the boot sequence continued). This made no difference.
• To workaround this, I booted the USB on another (old laptop) machine. This successfully went through the create install disc sequence.
• During the sequence, the mode of the display screen changed fonts, resolution etc – I presume this was when control was passed to the new kernel to deal with setup interactions (keyboard etc), and was the problem with running the sequence on the target hardware. I tried adding nomodeset in this situation too. It made no difference. Presumably the changed command line was not passed to a new run of the kernel – this is speculation.
• The system image created in this way suffers with the same problem as the installer – it loses touch with the screen during the boot sequence. Setting nomodeset in the kernel parameters using the grub editor allows the image to boot up consistently to the login prompt.
• I have made this permanent by editing /etc/default/grub (using nano as root) to change GRUB_CMDLINE_LINUX= "" to be GRUB_CMDLINE_LINUX= "nomodeset" and running grub2-mkconfig -o /boot/grub2/grub.cfg
• I updated the system running as root using zypper refesh; zypper up --no-recommends (which took some time and included a kernel update)
• I logged into the web interface and attempted to import my pool. This gave an error when mounting reporting /usr/bin/mount -t btrfs -o subvolid=331 /dev/disk/by-id/ata-HGST_HDN726050ALE610_NAG3N0RK /mnt2/Photos. rc = 32 reporting /mnt2/Photos: wrong fs type, bad option, bad superblock on /dev/sdd, missing codepage or helper program, or other error.
• Mounting the pool using the command line mount /dev/sda /mnt succeeded i.e. didn’t report an error. However, it only mounted the subvolumes readonly. The files can be read successfully.
• Trying mount -v i.e. verbose option to attempt to get more information yielded no difference. In fact, the mount command leaves a kernel message (accessed by dmesg | tail) suggesting that the btrfs option allow_unsupported=1 should be specified, but not why. (I’ve yet to find syslog on this system.)
• Using echo 1 > /sys/module/btrfs/parameters/allow_unsupported demonstrated that the pool could be mounted OK. I ran btrfs scrub start /mnt and btrfs check /dev/sda to make sure the pool was in good shape, and these ran to completion. The only output was that check warned some quota values were inconsistent. I believe Rockstor runs with quotas disabled in some way, so I guess this isn’t important.
• I had some difficulty setting allow_unsupported permanently – the suggestions elsewhere in the forum to modify a .conf file in /etc/modprobe.d/ to set the option didn’t work for me. However passing a further kernel option of btrfs. allow_unsupported=1 worked fine. This was implemented by adding this to the GRUB_CMDLINE_LINUX variable alongside the nomodeset option.
• The Opensuse documentation lists the reasons that is counts as unsupported for SLES (but not Leap as far as I can see). The list for SLES 15 is Automatic Defragmentation; In-band Deduplication; RAID 56; Device Replace; Seeding Devices; Inode Cache.
• Listing details using btrfs inspect-internal dump-super reveals the following flags: (MIXED_BACKREF | BIG_METADATA | EXTENDED_IREF | RAID56 | SKINNY_METADATA)
• The RAID56 flag is clearly an issue. Listing details using btrfs fi df /mnt reveals Data, single; System, RAID1; Metadata, RAID1; GlobalReserve, single. This is as expected – no RAID56. It Is not clear how to clear this wrongly set flag.
• There has been a bug corrected in btrfs in this area. Once the flag is set, it is never cleared, even when a balance is completed removing any raid5 or raid6 profiles.
• Ran btrfs fi balance start -dconvert=single -mconvert=raid1 /mnt to clear the flag. No change, so the volume is wrongly flagged and the unsupported option needs to be specified to mount it other than read only.
• Imported pool OK
• Imported (shares) configuration OK
• Started SAMBA service
• Accessing using Windows File Explorer. The server is visible, but no shares are.
• I’ve had a brief look at the samba.config; it doesn’t include the suggested line server role = standalone server

Recommendations

• Recommend balenaEtcher for creating installation discs on Windows, and deprecate rawrite32
• Make sure that nomodeset is always passed to the kernel whenever it is launched. There is no sense in changing modes on a text-based system which is normally run headless. Doing this should not make any machine that currently installs and boots Rockstor no longer do so, and will allow more machines to be supported by Rockstor out of the box. This ties in with the current Kernel parameter setting of plymouth.enable=0 which is presumably there for the much same reason.
• Document the symptoms of a pool mounting read only – the current diagnostics are obscure.
• Document a preferred method for setting allow_unsupported=1 for those who need it, with a suitable warning – I recommend editing /etc/default/grub as this ensures the option is in place whenever the mount occurs.
• Make it possible to ssh into Rockstor with the user that is setup in the web interface. It’s not good practice to require logging in as root for any necessary maintenance that can’t be performed with the web interface.

1 Like
2

@ajk Hello again and well done on an excellent report.

I’ll respond briefly for now as this is a lot of stuff to address in one go.

Thanks, we now have the following issue to address this:
https://github.com/rockstor/rockstor-doc/issues/360

Agreed. I’ve long resisted this move and have thought of it a number of times. It does seem a little heavy handed as many folks will then have the disadvantage/inelegance of massive text during install; but function must be favoured over form, hence:

https://github.com/rockstor/rockstor-installer/issues/100

This is especially important now given your report that a by-hand addition (our previous suggestion) appears not to work any-longer.
I proposed the use of this same option previously here:

But, alas I have to date not followed through with this seemingly heavy handed approach in our new installer in the hope this was somehow a thing of the past now. Oh well.

Thanks again for the detailed report on this and the confirmation that our current installer no longer works with the previously supplied work-around. Once we have this in place it would be good if you could confirm the fix as I no longer have access to my prior reproducer machine for this AMD video hardware bug.

The btrfs raid5/6 and/or unsupported thing:

Your experience here was a little weird as you likely had some left-overs or some other artifact as you intimate. However our recommendation is not to use the unsupported flag and second guess our upstream but to adopt the backported stable kernel. Hence the following new Howto:
https://rockstor.com/docs/howtos/stable_kernel_backport.html
which we link to from our raid profiles section:
https://rockstor.com/docs/interface/storage/pools-btrfs.html#redundancy-profiles
via a warning highlighted section.
We also have the following section for mounting ‘poorly’ pools such as yours may have been:
Import unwell Pool: Disks — Rockstor documentation
which in turn allows for an import as the command line mount point (/mnt2/pool-label) is compatible with our import code.

Yes this threw me at first also as I too also thought it was a SLES only thing. @Superfish1000 here talked me round:

Nice find. I’d have thought we already have that one. And if not it should be in the backported stable kernel we suggest for the parity raids. Interesting that you may have encountered this yourself.

Probably best not to use single if you can avoid it. Also note that a Rockstor balance will undo this and enforce dup I think it is on the metadata side if it finds a single data level. We are soon to embark on more flexibility/awareness of custom raid levels re mising and matching between data and metadata to do stuff like data raid6 metadata raid1c4 for 2 disk failure capability whilst avoiding some of the known parity raid issues currently. There is a note on this in the above stable backport kernel how-to.

The newer SAMBA in our upstream no longer enables the earlier smb protocols so you might like to try our newer Rock-on added to help in such browse capabilities added by @Hooverdan via:
https://github.com/rockstor/rockon-registry/pull/294
as a work around. A related forum thread by @Mike-B to that Rock-on addition is here:

I’m had thought we followed our upstream on this one. And if we disallowed root access then there would be not terminal available before the initial Web-UI setup. Tricky one this as if we go all out on security then we end up being potentially incredibly un-user friendly. I.e. blocking all ports unless a local console (not over network) purposefully opens it before we even have a Web-UI to start folks off. We are an end user appliance not a security device. We have also had suggestions that we have a default user and pass, in fact our new installer has this capability enabled by default but we stick with the console setup to avoid having a default root pass (or none) on every fresh install such as is the case with for example openwrt but we are considerably less constrained in that regard given many folks don’t have a serial-to-usb or the like to gain a terminal. Lets keep an eye on this one as I know opinions vary and we have had to enable some continuity for our prior CentOS based users who also had root ssh by default.

Again thanks for the details feedback. Always lot to improve on but there are at least a couple of easy wins here. We are still transitioning some of our docs to favour/include the new OS base so we do still have some confusing doc entries or out-right outdated/wrong stuff still.

Hope that helps.

2 Likes
3

A quick note on that one: I remembered seeing some discussion about that in the feature planning for Leap 15.4… see brief discussion below:
“Issue #23: sshd: prevent root login using password by default - features - Pagure for openSUSE” https://code.opensuse.org/leap/features/issue/23

2 Likes
4

Hi @ajk,

Let’s try to see what is going on with your Samba exports.

Did you make any customization to the Samba service when you configured it? Feel free to post a screenshot of its configuration dialog if you’d like.
Similarly, did you make any customization when creating your Samba export(s)? What does your Samba exports page look like? For reference, I’m talking about the following:
https://rockstor.com/docs/interface/storage/file_sharing/samba_ops.html

It could be also useful to verify your smb.conf looks as it should. It is located at /etc/samba/smb.conf. You can even paste its contents here if there’s nothing you mind sharing.

This should help us see whether this configuration is looking OK and we can then think of troubleshooting any connection issue there might be.

Hope this helps,

2 Likes
5

Thanks for the responses @phillxnet @Flox. I’ve been prodding at the Samba issue.

No - I wasn’t expecting to, and nothing I noticed suggested I should. I was expecting import to do any configuration needed. I was surprised that the samba service needed to be switched on.

I don’t know what I did when I initially set up the system. I did not create any Samba exports whilst reinstalling. I was expecting the import to do that.

Yes! It appears that the importing of the exported configuration did not populate the Samba configuration file. The file in the new installation contained the header but no share information.

    cat /etc/samba/smb.conf
[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####

I have copied the information describing the shares to Samba from the old installation e.g.

####BEGIN: Rockstor SAMBA CONFIG####
[Documents]
    comment = Samba-Export
    path = /mnt2/Documents
    browseable = yes
    read only = no
    guest ok = no
    admin users = ajk
    shadow:format = .snap_%Y%m%d%H%M
    shadow:basedir = /mnt2/Documents
    shadow:snapdir = ./
    shadow:sort = desc
    vfs objects = shadow_copy2
    veto files = /.snap*/
....
####END: Rockstor SAMBA CONFIG####

The shares are now visible and accessible. :smiley:

I noticed that in fact the NAS was visible under two names, ajkdatastor (it’s previous name and the name reflected in my etc\hosts file for example) and ajkdatastore with an extra ‘e’. Presumably this second was a typing error at some point when setting up the system.

I have managed to change this (by editing the name on the system/Appliances page), and now only the one host name appears on the network. However, presumably as a result, I get popup complaints saying ‘DataTables warning: table id= - Cannot reinitialise DataTable. For more information about this error, please see http://datatables.net/tn/3’.

Looking at the File Sharing/Samba page, no exports are defined there - presumably because I hand edited the samba.conf file.

I have looked at the contents of the exported back-up file. It contains two lines. Each line is a well-formed JSON sequence (although the file with both lines together is not well-formed). The first line describes the shares including entries like

{
  "fields": {
    "comment": "Samba-Export",
    "read_only": "no",
    "browsable": "yes",
    "snapshot_prefix": "snap",
    "share": 4,
    "shadow_copy": true,
    "guest_ok": "no",
    "path": "/mnt2/Documents"
  },
  "model": "storageadmin.sambashare",
  "pk": 1
},

which corresponds to the samba configuration entry I quoted above.

So that leaves the following questions:

  1. Why did the export of the samba configuration not get imported? Should the whole file be a well-formed JSON sequence? Is it possible that only one line of the backup file is being processed on import?
  2. Should I, and if so how should I, populate the Samba shares page? All is working at the moment, and I’m loath to disturb things further.
  3. Should I suppress the irritating pop-up from Datatables, or is there something I should do to put it right?

Again any advice gratefully received.

I converted to single a long time ago (using the command line). I use this machine purely for back-up copies of files, particularly video files that don’t live in the cloud. There is no need for the better availability that redundancy would provide. I’ll keep away from Rockstor balance!

I wasn’t suggesting you disallowed root access, but that you allowed access for the user defined during Rockstor setup. Currently /etc/ssh/sshd_config is explicitly changed by Rockstor to prohibit such access. Logging in as a regular user and using ‘sudo’ when necessary is a better model for Linux system access than always running as root.

3 Likes
6

@ajk Hello again.
Re:

This is an unrelated bug in our tools (libraries) and likely improvements we need to add in some places. A browser refresh button press normally sorts this issue out. We have ‘fixed’ this is a number of places but it still pops up from time to time.

Correct. Probably best you re-add them informed from your prior config entry. Likely the samba share restore failed on this front. The pool import brings in the shares but not he exports. The exports are supposed to be restored by the config restore.

That’s not an issue we ‘wrap’ multiple jsons in our config backup file.

We have seen the occasional report of failures on this front. We have also made some improvements to the config restore but it still likely has some bugs in it. You report here is useful in reaffirming our suspicion that on occasions the smb exports are sometimes skipped for some reason.

You can always re-assert your existing smb.conf file so can take a copy of it as-is before then re-asserting hopefully the same config but via the Web-UI by re-creating the same samba exports. You can always check on what the Web-UI is doing to the smb.conf file as you go. It’s fairly clear to see what changes it makes as it goes.

Just do a browser refresh button press. That usually sees to it for quite some time. There is some kind of Web-UI ordering that regenerates this message. Once we have a reliable way of reproducing this issue we can likely track down exactly where it’s being generated from and prove a consequent fix. Do let us know if you manage to find such a reproducer. It’s unrelated to your current ‘other’ issue however.

OK, but note that single also looses the pools ability to self-repair if a corruption does occur. But it can still report that corruption and the file it belongs to so there’s that.

OK,

Yes, we were trying to play safe as best we could.

Agreed. And @Flox’s findings re Leap 15.4 looks like we will be taken in that direction anyway. Note also that we default to user (Admin user in this case) login via the Web-UI shellinabox implementation and not root access directly that way. But do allow it as a config option. Take a look at that implementation our of curiosity maybe. We also enforce a chroot in that setting which has also caused some grief / miss-understanding for some users. All in I think we are likely to move (at the OS level) in the direction you indicate as we, in time, re-base on 15.4. But we have our Python 2 -> 3 move to do before that of course.

Thanks for the reports here. Much appreciated. And of course do let us know how that samba export re-add via Web-UI goes. All we really do at the system level for that is edit the smb.conf and enable stop/start the service so you can clearly see what is done to that file as you make Web-UI changes. Just take care not to hold a lock on it if you have it open at the time. You could ‘tail -f’ it I believe, as you make the Web-UI changes. But note that once entered into the Web-UI it will try to enforce those changes into the smb.conf file. I.e. the source of truth is what the user has entered into the Web-UI. Hence our remarks within that file as to what we change.

Hope that helps and thanks for the confirmation on the occasional failiure of samba export restore. Again we have yet to establish a reliable re-producer for this to develop and provide a fix. But all in good time.

1 Like
7

@phillxnet I’ve reinstated the shares as seen by Rockstor using the File sharing/samba page. I merely added the shares without deleting the config file file in use, and the entries were updated without any complaints. The contents of entries in the samba.conf files look a bit different (no ‘root preexec’ fields - instead some ‘shadow:…’ fields and the like), but no doubt they are as they should be.

The irritating popups have gone away. (You might try editing the Appliance hostname to provoke them - that seemed to trigger it for me.)

Thanks for your help and advice. Let’s hope other HP Microserver users have an easier ride!

2 Likes