I just installed a fresh suse leap 15.1 and tried
zypper addrepo -f http://updates.rockstor.com:8999/rockstor-testing/leap/15.1/
but the response was
If only one argument is used, it must be a URI pointing to a .repo file.
addrepo (ar) [OPTIONS] <URI> <ALIAS>
addrepo (ar) [OPTIONS] <FILE.repo>
adding rockstor as last parameter fixed the problem though.
@Marenz Thanks for the head up on my forgetting the repo name.
I’ve now updated the original post and I think it’s important to use the name given there, ie:
Rockstor-Testing
This should allow the resulting rpm install to then manage that repo via the Web-UI and, when it becomes available, be able to supplant it with the Stable repo, and visa-versa. Otherwise the testing repo you have put in under the name “rockstor” will be co-resident and nullify the Web-UI’s capability to mange these repos for folks.
This was a silly mistake on my part and I think I remember thinking I should go check on the exact name before posting and then getting distracted and ending up putting in no name at all!
So for testing it is important that these repo names be exactly “Rockstor-Testing” and nothing else. So for those who have already put in repos named otherwise I’d recommend deleting these and adding again as per my now @Marenz prompted correction in the original post.
Thanks again for the heads up and apologies for slipping up on this rather important config element.
And Thanks for helping to test the ‘Alpha’ testing releases.
I’ve just released, slightly behind our Leap15.1 and to-be deprecated CentOS 3.9.2-52 rpms, our Tumbleweed equivalent. It was a little delayed as there was a build issue that only held up the Tumbleweed build and I didn’t want to delay the others for this.
This has now been fixed and merged into master and I’ve released a new Tumbleweed rpm only as this is the only change and it only really affected Tumbleweed, I’ve versioned the Tumbleweed rpm accordingly:
given it’s identical to the other 3.9.2-52 rpms but for the build fix.
Hopefully from here on in we can return to simultaneous releases, which is the intention during the transition over to our “Built on openSUSE” offering and until we reach feature parity or near enough.
And post Web-UI initiated rockstor package update we have, on this fully updated Tumblweed:
Our main focus in on Leap15.1 but Tumbleweed is serving well as an early warning system for; package changes, btrfs command output format changes, and the like.
Lets hope this encourages more alpha testers to jump in.
Thanks to @def_monk and @Flox for finding another requirement relevant to trialling our current “Built on openSUSE” rpms out.
I’ve updated the canonical “openSUSE dev notes and status” technical wiki entry accordingly and further emphasised that doc’s changing nature in this threads original post. In short the addition, a hard won finding, is as follows:
systemctl stop apparmor
systemctl disable apparmor
for Rockstor initiated samba shares to be accessible. Please read the dev notes for our prior status re SELinux and our plans/hopes re apparmor.
Hope that helps our early adopters of the testing channel re-launch to get just a little bit further.
The only thing I have struggled with so far after a clean install of Tumbleweed and Rockstor today is that the default systemd smb.service file in Tumbleweed is broken.
Trying to start Samba with systemctl start smb.service I was getting:
Feb 11 00:30:41 rockstor systemd[1]: Starting Samba SMB Daemon…
Feb 11 00:30:41 rockstor smbd[5602]: [2020/02/11 00:30:41.674112, 0] …/…/lib/util/become_daemon.c:135(daemon_ready)
Feb 11 00:30:41 rockstor smbd[5602]: daemon_ready: daemon ‘smbd’ finished starting up and ready to serve connections
Feb 11 00:30:41 rockstor systemd[1]: smb.service: Failed with result ‘protocol’.
Feb 11 00:30:41 rockstor systemd[1]: Failed to start Samba SMB Daemon.
The smb service logs indicated no problem:
[2020/02/11 00:30:41.657055, 0] …/…/source3/smbd/server.c:1775(main)
smbd version 4.11.5-git.114.5685848b8fcSUSE-oS15.5-x86_64 started.
Copyright Andrew Tridgell and the Samba Team 1992-2019
[2020/02/11 00:30:41.674112, 0] …/…/lib/util/become_daemon.c:135(daemon_ready)
daemon_ready: daemon ‘smbd’ finished starting up and ready to serve connections
After much wailing and gnashing of teeth it turns out the fix is to update a line in the following file
/etc/systemd/system/smb.service
Change the line:
ExecStart=/usr/sbin/smbd $SMBDOPTIONS
To:
ExecStart=/usr/sbin/smbd --foreground --no-process-group $SMBDOPTIONS
Then run:
systemctl daemon-reload
systemctl status smb.service
And all (so far) is right with the world.
This is from https://git.samba.org/?p=samba.git;a=commitdiff;h=8b6f58194da7e849cdb9d20712dff49b17a93a77
which was posted in 2017
@gaspode Hello again.
It’s actually rockstor’s ‘default’ smb.conf file that is broken, the default in Leap15.1 (our main focus) and presumably Tumbleweed already has this line in place. We are planning to do things differently here than we have done to date and have already implemented our newer system to get docker working in the two openSUSE targets. If you take a look at @Flox recently opened issue you will see what is planned. This looks very much like it will sort the problem you encountered.
https://github.com/rockstor/rockstor-core/issues/2127
Well done on finding the fix but the fault is all ours as we overwrite the smb.conf with a now old, and fine for CentOS template. We are moving to sourcing the package default found and edit it to create our initial template, such as we now do for docker (in our openSUSE variants only).
Thanks for sharing your work around, and until we get this recent issue’s pull request prepared and merged your advise is relevant. Do take a look at the issue though as @Flox indicates the where and what of the upstream distro’s default samba which for those having difficulties is an important reference untill we get out ‘old ways’ template system updated. @def_monk and @Flox have just been battling with samba so more input on this is very timely. Thanks again.
Do also take a look at the btrfs backport comparisons between Leap15.1 and Tumbleweed in the following post as Leap 15.1 is kept surprisingly up to date on these:
Thanks again for sharing your findings and do keep the reports coming. Much appreciated.
Thanks a lot for sharing your findings, @gaspode.
@phillxnet already explained everything but your timing couldn’t have been better as I was installing a fresh Tumbleweed just to double-check its smb.service default configuration just as you were writing your post.
I could thus verify that the Tumbleweed defaults are the same as Leap 15.1 ones (for smb.service), so that should simplify (and thus speed up) our work on this. I’m hoping to be able to start working on this in the coming days so we might have that resolved in the very near future as that is a priority (for me, at least) at the moment.
Thanks a lot for your report and confirming that is the right way to approach this… that makes everything a lot more motivating and always give a smile 
.
Thanks again.
Ahh, well good to know OpenSUSE aren’t that far behind in squashing bugs and are fully committed to creating new ones 
I was running a 5.1 series kernel (I have a recent Ryzen system) on the old CentOS install, and was in the process on upgrading to a 5.5 kernel when I had a late night brain fart and managed to uninstall Rockstor.
So as I’d have to reinstall it anyway I thought I may as well migrate to the new SUSE codebase.
If Tumbleweed lets me down I’ll swicth to LEAP. but it’s working now so…
Running Leap 5.1 on the beta channel, here.
I don’t have a problem starting the samba service and creating shares, but I absolutely can’t access my shares from my windows machine, no matter what password/user combination I try (even though guest access should also work, too).
I do see the shares listed though.
The journalctl -f command also didn’t yield any output at all upon failed login attempts…
Maybe I am just too early and it isn’t expected yet to work? In any case, let me know if I can help debugging this in any way.
@Marenz Hello again.
Did you do the following from an earlier post:
Hope that helps, and thank for the offer of assistance. We are due for another release very soon so will note that here when it’s published. It contains a improvement to our Samba config on openSUSE by @Flox.
Ah, no I did not. I just assumed the last update addressed this. Will try when I get home.
I am now running 3.9.2-54. Before the update, I stopped and disabled apparmor now, recreated my shares, restarted the smb service, restarted the whole server, but I still can’t browse my share, always authentication failure (even though guest access should work, too).
To the ‘Built on openSUSE’ early-adopters/developers:
Just a quick note that we have a new requirement re disabling IPv6 via grub. All details in the canonical wiki under a new section entitled:
Thanks to @tyukh for diligently chasing this one down. Referencing their GitHub issue for context:
Hi @Marenz,
I would like to first apologize for letting your message unanswered for several days… I wanted to get back with you earlier than that, but my current schedule is a lot busier than usual and leaves me with very little time to spend here.
Maybe a dedicated forum thread would be more appropriate to your issue, and we would then report here any fix or resolution that may come out of it. This way we could keep this “Announcement” thread as focused as possible.
To your issue now, I unfortunately am not aware of a single way to troubleshoot samba that would tell us everything, as so many factors are at play. I would thus start with the most obvious things (that you most likely already tried), but I’d rather make sure of these elements first before diving into something more complex than we should have been.
First, you have already done so, but I would make sure we start from a clean plate by deleting all your samba exports, and turning off your Samba service. Then, make sure apparmor is indeed turned OFF with systemctl status apparmor.
Second, click on the configure Samba service in the webUI, and make sure to fill in your WORKGROUP. Do you also use to use custom global options or did you use to let it blank?
Third, click submit to save the configuration file. You can also verify that all was written correctly by looking at the file: cat /etc/samba/smb.conf.
Fourth, toggle the Samba service ON. When troubleshooting like that, I usually like to have a terminal session open at the same time and monitor the logs with journalctl -f so that I can see what is happening. You should see mentions that smb and nmb are turning ON, and then a message from nmb telling you that this computer is now the master of your workgroup after a few seconds (that one can take a minute to appear sometimes).
Fifth, export one share with the settings you’d like, and make sure the settings were correctly applied to /etc/samba/smb.conf. If you are still monitoring the system logs, you should see that the Samba service is restarted to refresh its configuration (which means the same messages as in step 4 above should appear).
Sixth, regarding your client, you mentioned windows, but can you tell us which version by any chance? Also, you said you were able to see your share exported correctly, but were having an issue trying to connect to it: could you get more information? Are you using the WORKGROUP\user format for the username? Would you be lucky enough to have an explicit error message? I know Windows is terrible at giving useful information in its error messages, unfortunately, so we usually only get a useless “Acces denied”…
The best way to see what is happening is to monitor the samba logs themselves: /var/log/samba/*.log if my memory is correct. You will see several ones and all will have different information. You could try to monitor all of them at once while trying to (1) see the share from your Windows client and (2) after entering your credentials and actually trying to access it, but we will probably be drowned in information. Best chance at first would be to monitor the following ones at first:
smb.logYou will see a lot of information, and warning messages as well, but hopefully these would prove helpful. There’s a lot more troubleshooting that can be done as well, but let’s start with that at first, at least.
Hope this helps,
We now have 3.9.2-55 “Built on openSUSE” testing rpm out but note that, to address one of the few remaining feature parity issues, we needed to add an additional repo to cover the shellinabox package dependency. Details are in the usual place:
Web-UI updates will most likely fail until you have done this extra step.
Cheers.
Hello, seems like some great progress is being made. I’m curious if there is an “upgrade” path for those on the CentOS version, if we want to migrate over.
Is it as “simple” as taking a backup of the config on CentOS (and saving that off). Then installing a new USB stick with the OpenSUSE build, and then restoring the config I backed up? I’m assuming my btrfs pools will be detected, but will things like Shares, NFS mounts, SMB mounts, etc all also be detected?
@kupan787 Hello again.
Currently the Built on openSUSE Stable channel is un-populate but that’s only a matter of time hopefully. And out release target disto is likely to be Leap15.2 but re:
Pretty much yes. But note that you should only use high performance USB sticks, if you have to use this medium for the system disk, and ideally a real hdd,ssd is always preferred. And it’s best to import your pool once all of the above ‘early-adopter’ config and prep is done, and only then restore your configuration. The two operations are separate. That way the config restore has existing imported shares etc to map the config restore elements to. As to what is backed up and restored that is as per our following doc section:
Configuration Backup and Restore: http://rockstor.com/docs/config_backup/config_backup.html
With the caveat that we have now dropped AFP.
In time we should be ready to release our ‘Built on openSUSE’ installer but that will likely no be until after Leap15.2 is out anyway, so currently one has to just do a server install of Leap and config as per in the original post in this thread and it’s linked wiki entry here on the forum. But I’m hoping to release the kiwi build config for it much sooner. All a work in progress though and we have working prototypes for 15.1/2 and Tumbleweed.
We’ve only recently added server status restore to config save/restore and there has been a report by @shocker of some initial sync issues. The thread is labelled openSUSE but I’m pretty sure it’s actually generic:
So hopefully we can look to that soon as it seems to affect, from that report, a number of the services.
So look out for that. Also note the dev wiki link for known outstanding openSUSE variant related issues like no share on the system drive. But we are definitely getting there.
Do take a fresh look at this threads original post as I’ve recently edited it to make it clearer and hopefully easier to follow. It’s still early adopters but if you are comfortable with a little command line and happy to chip in with informed reports then great. I’d go for Leap15.2beta given it’s only a week or so from package freeze and has a much newer kernel base. All openSUSE variants get aggressive btrfs backport but it’s still nice to have newer kernel base.
As you have no doubt seen there are now a few active and technically knowledgeable/capable forum members who have taken the plunge and more of the same can only help. But the original message of this thread still stands. That we are more after solutions to reported problems, or at least strong pointer, than simple reports of their existence. But is can only help to have more folks involved. See how you feel, but if you are after a tailored installer and are not familiar with cli/systemd etc then it’s not quite ready yet.
Bit of a chicken and egg really but given few have as yet tried it to my knowledge you may well have surprises but if you can drill into these yourself a bit and are prepared to chip in then super; go for it. If nothing else you data may in fact be better maintained on the newer Leap15.1/2 base than it is currently in our CentOS offering. But ideally we await the Leap 15.2 release proper. And if you are in two minds then I would suggest waiting for the 15.2 release first. I believe it’s due out proper beginning of July. And if that’s just too long then jump on the Leap15.1 testing.
On a related note re newer kernels I’ve still not gotten around to addressing what you brought up here:
So if you did fancy picking that back up then great: pull requests welcome. Especially given the kernel versions now in Leap15.2beta (5.3.18-lp-152.10-default) and Tumbleweed (5.6.2-1-default) as of a few days ago. But remember that if doing a source install then do it in a separate dir i.e. “/opt/rockstor-dev” not the default rpm one. That way you can more easily jump back to an rpm install with the caveat that it will always be like a fresh install to go between them, i.e. config save, import pool, restore method again as the db is necessarily wiped during this source/rpm (and reverse) process.
Hope that helps.
I just tested that quickly, but noticed that the current Leap15.2 beta is still using Btrfs-progs 4.19.1 (with kernel 5.3.18) so the btrfs scrub satus output format is still OK for us. Only tumbleweed should have this problem. I know it’s only a matter of time, though, so it looks like we still need to account for the btrfs-progs version when applying this fix.
For instance, I have:
rockdev:~ # btrfs --version
btrfs-progs v4.19.1
rockdev:~ # uname -a
Linux rockdev 5.3.18-lp152.11-default #1 SMP Wed Apr 15 12:02:19 UTC 2020 (71e1af4) x86_64 x86_64 x86_64 GNU/Linux
…which gives me:
rockdev:~ # btrfs scrub status -R /mnt2/test_pool
scrub status for 18ed12fc-fa61-4076-b522-3e37f4e6e9d7
scrub started at Wed Apr 29 08:14:05 2020 and finished after 00:00:00
data_extents_scrubbed: 1
tree_extents_scrubbed: 18
data_bytes_scrubbed: 65536
tree_bytes_scrubbed: 294912
read_errors: 0
csum_errors: 0
verify_errors: 0
no_csum: 16
csum_discards: 0
super_errors: 0
malloc_errors: 0
uncorrectable_errors: 0
unverified_errors: 0
corrected_errors: 0
last_physical: 1179648000
…that itself is picked up nicely by the webUI:
I don’t know whether or not Leap 15.2 will ship with newer btrgs-progs version, however.
So I am still on CentOS, but I’ve been upgrading my kernel and btrfs progs:
[root@rocknas ~]# btrfs --version
btrfs-progs v5.6
[root@rocknas ~]# uname -a
Linux rocknas 5.6.7-1.el7.elrepo.x86_64 #1 SMP Wed Apr 22 18:05:11 EDT 2020 x86_64 x86_64 x86_64 GNU/Linux
And here is what btrfs scrub looks like:
[root@rocknas ~]# btrfs scrub status -R /mnt2/MainPool
UUID: 23cad14d-6fec-4482-997c-d62021de832a
Scrub started: Wed Apr 15 00:05:04 2020
Status: finished
Duration: 10:49:34
data_extents_scrubbed: 660905136
tree_extents_scrubbed: 2753807
data_bytes_scrubbed: 43241772498944
tree_bytes_scrubbed: 45118373888
read_errors: 0
csum_errors: 0
verify_errors: 0
no_csum: 491699192
csum_discards: 0
super_errors: 0
malloc_errors: 0
uncorrectable_errors: 0
unverified_errors: 0
corrected_errors: 0
last_physical: 5688272945152
And without the -R:
[root@rocknas ~]# btrfs scrub status /mnt2/MainPool
UUID: 23cad14d-6fec-4482-997c-d62021de832a
Scrub started: Wed Apr 15 00:05:04 2020
Status: finished
Duration: 10:49:34
Total to scrub: 40.03TiB
Rate: 1.03GiB/s
Error summary: no errors found
A while back I tried to do some work to identify the btrfs progs version, and update the output. It is a little “hack-y”, so if I get some time, I’ll try and clean it up and submit a pull request. But I also made a few changes to my UI, to incorporate some of the fields that I think are new (not sure if they are in the old version of not):
Here I added a SCRUB rate column. I also made the End Time display the ETA while a scrub is in progress.
Here I added the ETA column and the Scrub Rate column.
These changes were obviously for myself per my preference, so might not fit into the overall direction of Rockstor.
However, the fixes to parse the SCRUB output will be needed once you get to a more modern btrfs-progs. I’m surprised that tumbleweed would have a newer kernel, but still be using the older btrfs-progs.
@kupan787 Thanks for following up on this one.
I for one like both of your Web-UI addition, but we will have to wait for the btrfs-progs update in Leap15.2beta to have those otherwise we just get blank columns. Unless your game to do a fail over in the Web-UI layer say something like, ie ‘not available’ when running on older btrfs-progs. I think @Flox was saying that the Tumbleweed does have newer btrfsprogs only the Leap15.2beta is trailing on that front. But for the Tumbleweed we have the deprecated python2 packages issue, hence the Leap15.2beta target currently. Once we are done with the feature parity and establishing the new Stable channel for the Leap15.2, once it’s out of beta, we can begin with our Python 3 move. And some progress has been made on that front already but the distro move has been a higher priority.
