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.
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.
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).
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.log
the one having your client’s IP in its name
the one having your client’s hostname in its name
You 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.
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:
Add ‘shells’ OBS repo
Web-UI updates will most likely fail until you have done this extra step.
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?
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:
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.
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
[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 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.
There are a couple of other items that the newer kernels/btrfs-progs offer. Namely:
zstd compression
RAID1C3 and RAID1C4
Adding the zstd compression I think should be pretty straight forward (I got it half implemented on my end right now). If I get some time in the next few weeks, I’ll try and put together another pull request for that (if you guys are ok with it).
As for RAID1C3 and RAID1C4, by themselves they are interesting due to how btrfs does RAID1. However, from what I have read, they are more investing when used for the Metadata on a RAID5 or RAID6. In the current setup, I don’t think Rockstor has a way to specify the RAID level of the Data vs the Metadata. So this kind of an enhancement might be a little more involved.
Not sure if you guys have a roadmap, and if adding these features are on it, but might be something to consider down the road once the cut over to openSUSE is done.
That would be great. And yes, should just be allowing it as an option and reporting it correctly there after. But theres also the kernel version issue but soon we are going to have to set a minimum kernel version we ‘support’ and it’s likely to be whatever Leap15.2 arrives with and it’s associated back-ports.
Agreed, but we could start by surfacing within the Web-UI the raid levels and take it from there. We currently fudge these a little and favour the data for reporting I believe, from memory. But getting them both in the Web-UI and through-out the models etc would be great. But this ‘level’ of stuff has to have unit test coverage and there exists already a test for the reporting bit so looking to that would be a good starting point.
Again from memory I think we have the facility to track this but just don’t, so you may well find stuff in place already. Again it’s been a while since I looked at the code from that angle. Also many fencing issues with regard to what we don’t allow will have to be revised once we introduce new levels, i.e. min number of disk etc. But yes it would be fantastic to at least start to report the metadata as well as data raid levels. And from that unit test it looks like we collect the lot already at the lowest level. It’s just fudged later to represent only data.
Exactly. Our current focus is on feature parity with our CentOS variant (very close) so we can establish the new ‘Built on openSUSE’ Stable Channel rpms. There after we can steam into this stuff in the testing channel, but we first have to do the little matter of the Python 3 changeover !! But all doable and in progress.
Bit by Bit, and I’m looking forward to where we are going on all of this.
@kupan787 Re your pull request. I’m all ready to merge but just want to give you the chance to do a linked issue. That way we get clearer attribution in the Changelog. We have some other pending changes to these same files that I’d like to rebase on top of your changes before pr submission so if you could pop in a simple issue then I can get the links sorted and the pr merged. I can then do a Fixes issue-number in the merge commit and it makes things easier to find / track later on. And gives us a clean way to create the changelog that is then displayed within the Web-UI.
Cheers. And thanks again for stepping up to this one.
3.9.2-58 testing will require a reboot after the rockstor package update.
The system pool is now mounted differently to address one of the last major feature parity issues when compared with our current Stable channel release.
N.B. No ROOT/system pool shares or snapshots will be visible within the Web-UI until after the required reboot.
Enjoy, and remember to keep those early adopter reports coming in. We are definitely getting there now.
I will formally announce this release shortly, if all goes well here, in a fresh forum thread aimed at a wider audience as we edge ever close to feature parity with our current (3.9.2-57) Stable Channel release (CentOS only for now). I think we are now ready to call 3.9.2-58 our beta testing release. Again, as always, all constructive input is welcome. But this looks more like a beta to me now. Packages available shortly for Leap 15.1, Leap 15.2 beta (our main target), and Tumbleweed (if you already have installed, or can find, the required python 2 dependencies).
After the update the shares on my root pool seem a bit messed up. The pool previously had snapshots enabled (default setting, I never did anything to the root pool). All the custom shares (so the non-home share) are now at /@/.snapshots/1/snapshot/ and seem to have lost all data.
Further, the root pool now has a red “quotas disabled” status.
EDIT: I just checked, the data is still there on disk, it’s just that the path of the shares no longer matches.
