I can be stubborn at times with this kind of things, and it bothers me not to be able to figure that one out. I tested with yet another debian-based server acting as the Samba server, and I still see the same behavior than with Rockstor or with a base Leap 15.4 installation. The more I try, the more I think it’s unrelated to the Samba config, especially given all the testing you have done on your end.
I’ll keep poking at it as I can…
Thanks, @Flox.
I am thinking the same thing (not a Samba config), but then I can’t think of anything else that would cause it. So, so strange.
Have you tried to add Rockstor / Rockstor-i3 hostnames to /etc/hosts, to get rid of those errors (have been known to cause slowness)?
This!
I couldn’t believe it, but simply adding
192.168.0.30 Rockstor
to my hosts file was all it took. The difference is night and day! My write speed went from this:
to this:
I then removed the entry, and it slowed way down again. Then after putting it back in, it sped right back up.
The interesting thing is that I checked my Ubuntu server, and it doesn’t have any entry in the hosts file (besides localhost). So no idea why that one works fine w/o it, but Samba on Rockstor did. But I’ll treat this like I do everything Linux. I may not understand it, but I’m just happy that it works.
Thanks @Jorma_Tuomainen for getting this fixed for me! And thanks again, @Flox and @Hooverdan for all the time that you put into helping me. This was such a strange problem, and it made sense to try all the things that you suggested to get more info and rule things out. I was thinking I’d overwrite with Ubuntu by the weekend, so now I can really give Rockstor a shot as my permanent NAS solution!
Great news! I’m glad you got it resolved!
Thank you so much for saving the day, @Jorma_Tuomainen!
Maybe we can think of doing this automatically for users when turning the Samba service ON as I suspect it would affect quite a few users. We would need to be careful about it, though, as I don’t want Rockstor to impose a configuration of /etc/hosts upon users who may not want it for their own reason(s). Maybe as an option when configuring the Samba service… It’s worth thinking about it at least.
@orangejulio, from all the different things I had you test in vain, I think there is one worth considering keeping: adding vfs objects = btrfs to your Samba export customization. While it has not been thoroughly tested by us yet, this is something we are seriously thinking of adding by default as it is designed to bring some nice performance improvements when copying files within the share, for instance (if I recall correctly). It also has been around for quite some time now.
Either way, let us know how things go, and thanks for opening this thread!
It’s always DNS.
Well in this case local name resolution but it’s the same thing 
Sure, I have no problem adding that. I think it would be preferable to help both performance and disk space.
I just tested it, but I don’t think it’s taking effect, as a copy test (from one folder to another on the same share) is taking the same amount of time and has similar network activity. I added that line to the Samba entry for one of my shares (temp), stopped and then re-started Samba. Went back and forth a few times, but all seemed to be about the same. Below are the network activity graphs (first few seconds of each are missing due to me switching back to the dashboard).
Did I implement it correctly, or is there something else I should be doing to enable it?
w/o vfs objects = btrfs:
with vfs objects = btrfs
[temp]
root preexec = “/opt/rockstor/.venv/bin/mnt-share temp”
root preexec close = yes
comment = Samba-Export
path = /mnt2/temp
browseable = yes
read only = no
guest ok = no
shadow:format = .temp-monthly_%Y%m%d%H%M
shadow:basedir = /mnt2/temp
shadow:snapdir = ./
shadow:sort = desc
shadow:localtime = yes
vfs objects = shadow_copy2
veto files = /.temp-monthly*/
valid users = mediashare
vfs objects = btrfs
Not sure whether that makes the difference, but you have the vfs objects parameter listed twice (for shadow copy and for btrfs). My understanding is that you place all vfs objects in one line (separated by space), so it would be (assuming they’re loaded and used in order):
vfs objects = btrfs shadow_copy2
Or am I mistaken?
I believe @Hooverdan may have the explanation here. That being said, I have not found time to check how to properly test this module.
Nevertheless, you may have just found a little limitation in the ability to input VFS objects as customization. We indeed need the shadow _ copy one because you checked the windows snapshot checkbox; but the customization you entered was not aware of that. We will need to make that more “smart” to account for this kind of scenario.
In the meantime, you can test it manually but it will be overridden every time you edit a samba export or toggle the samba service ON/OFF using the UI. If you want to test it manually, you can export the share without specifying the btrfs object in the customization box, then manually edit smb.conf as @Hooverdan detailed, and then restart the SBA service manually (systemctl restart smb nmb).
Good catch.
As the first entry (shadow copy) was auto-generated, I manually updated the file to include both entries on one line as you suggested.
After more testing, I am now thinking that it is doing btrfs de-duped copies whether or not that flag is set. To make the test more consistent, I started copying a larger folder with larger files (3 files, 10 GB total). What I am seeing is that the xfer speeds are way beyond what my 1 gbps network can support, even without adding the btrfs flag.
So I’m not sure that this setting is needed. I tested it both with and without the btrfs flag, and the speed is similarly great. If I’m missing something here, let me know please.
no btrfs flag set:
[temp]
root preexec = “/opt/rockstor/.venv/bin/mnt-share temp”
root preexec close = yes
comment = Samba-Export
path = /mnt2/temp
browseable = yes
read only = no
guest ok = no
shadow:format = .temp-monthly_%Y%m%d%H%M
shadow:basedir = /mnt2/temp
shadow:snapdir = ./
shadow:sort = desc
shadow:localtime = yes
vfs objects = shadow_copy2
veto files = /.temp-monthly*/
valid users = mediashare
@Flox I didn’t see your reply until after I replied to @Hooverdan.
In my limited experience, it appears that Rockstor will let you start/stop Samba without over-writing a manually-modified smb.conf. It seems to only alter the config if I make a change to a share (and presumably to the global config as well). But just to be sure, I redid the manual editing and did the manual restart each time.
Whether or not I have the btrfs flag in there (on the same line as the shadow_copy, the speeds are really high, and it’s clearly not actually transferring all the data back and forth over the network.
My thinking is that samba already knows that it’s a btrfs filesystem and is taking advantage of that already. Seems like that’s not expected behavior, but that’s what I’m seeing here. It would probably be good to have someone else test this as well.
No worries… I think I saw your message right as I was tapping the “submit” button.
Thanks a lot for testing that; it’s actually really informative and valuable. I’ll try to provide some elements of answers here and there.
Correct; it seems I was mis-remembering. There are pretty much 4 scenarios:
systemctl restart smb. Rockstor doesn’t even know when you do that so there is no change in smb.conf. Rocsktor still checks the status of smb.service when you visit the “Services” or “Samba exports” pages, though.smb.conf.smb.conf.Impressive speeds indeed! Samba supports server-side copy since v4.1, it seems, which means that transfer over the network should NOT happen when copying a file within the same Samba share from the client. What the btrfs vfs object brings on top of that, is that you shouldn’t see disk activity either when doing that. See the following section of the Samba wiki for a much better explanation: Server-Side Copy - SambaWiki. Now, it is possible that recent Samba/kernel versions have a much better support for COW, which would make that aspect of the btrfs vfs object not that useful. That may be why you see what you see).
Now, the btrfs object does bring a bit more than that, and allow support for transparent file compression from Windows, for instance. See the nice section of openSUSE Leap’s docs on the matter: Samba | Reference | openSUSE Leap 15.5.
Thanks again for reporting this; that is extremely valuable.
I have created a corresponding issue (and referenced other vfs open items) to address the approach on how to deal with vfs modules in general via the Web-UI:
Hope, this is fine.
Thanks for all the extra info, @Flox.
I think I am understanding it more. My speeds were high enough that it implies that it wasn’t doing any disk copying of the data, but I think I need to do more tests to actually prove it.
When I have a little more time I will set up a fresh share and do something conclusive, such as copying a very large file and taking snapshots and checking for unique data in them.
Regarding the ability to set compression from the Windows properties dialog, I did not have that option on mine. It didn’t have a button for ‘advanced.’ This laptop is on Win 11, so it may be different. Or since I have in enabled on the entire pool, perhaps it doesn’t share the option. I’ll try to look more into that, too.
Just following up after doing some more tests. I am not totally confident that regardless of whether vfs object = btrfs is set or not.
I created 2 new shares, one on my main data SSD (SATA) and another on the root volume (NVME) and exposed both via samba (default settings, so no vfs object param).
I copied a single 7.9 GB file to each of those shares. As expected per @Flox’s comments/links, there was no network transfer to or from my desktop. The copy to the SATA drive averaged 95 MB/s, which is reasonable given that it’s not a high end drive and is reading and writing from the same device. The copy to the NVME share was much faster at 280 MB/s. So that was working as designed.
I then made a copy of each of those files into the same directory. It was effectively instant in both cases, as the Windows copy window never even popped up. This tells me that it is already supporting COW out-of-the-box.
I then set vfs object = btrfs on both shares and restarted Samba. Same result, instant copies. However, I could now see the advanced button that let me set compression. This was on a Win 10 desktop. I went back to the Win 11 laptop, and I was able to see it on there as well. So I must have gotten confused earlier and checked it when it was not enabled.
I then enabled shadow copy and manually added the btrfs flag:
vfs object = btrfs shadow_copy2.
I could access the compression successfully.
Then I restored it to vfs object = shadow_copy2 and added a 2nd entry for vfs object = btrfs. The compression option available this way, too, so it appears it doesn’t matter whether it’s combined or on a separate line. That means users should be able to add it themselves to a share on top of shadow copy, even without it being built-in to Rockstor.
Note that in both Win 10 and 11, there was no visual cue as to whether files were compressed. Per the link it should have colored the file names blue.
Hope this helps.
With vfs object = btrfs:
Without vfs object = btrfs:
Well that’s interesting… rather confusing results but still very helpful.
That’s a great demonstration that not only does the server-side copy work, but so COW support.
I tested something related to the following:
I couldn’t find a clear answer in the manuals or elsewhere on how Samba deals with multiple definitions of vfs objects = for instance, so I tested it using the Samba testparm utility (testparm) as it returns the “parsed” version of the options defined in smb.conf.
rockdev:~ # grep "vfs objects" /etc/samba/smb.conf
vfs objects = btrfs
Gives:
rockdev:~ # testparm -s | grep "vfs objects"
Load smb config files from /etc/samba/smb.conf
Loaded services file OK.
Weak crypto is allowed
Server role: ROLE_STANDALONE
vfs objects = btrfs
rockdev:~ # testparm -s | grep "vfs objects"
Load smb config files from /etc/samba/smb.conf
Loaded services file OK.
Weak crypto is allowed
Server role: ROLE_STANDALONE
vfs objects = shadow_copy2
Gives:
rockdev:~ # testparm -s | grep "vfs objects"
Load smb config files from /etc/samba/smb.conf
Loaded services file OK.
Weak crypto is allowed
Server role: ROLE_STANDALONE
vfs objects = shadow_copy2
So, it seems only the last definition is kept.
Trying with the definitions of these in the opposite order, to match the order you had:
rockdev:~ # grep "vfs objects" /etc/samba/smb.conf
vfs objects = shadow_copy2
vfs objects = btrfs
Gives:
Load smb config files from /etc/samba/smb.conf
Loaded services file OK.
Weak crypto is allowed
Server role: ROLE_STANDALONE
vfs objects = btrfs
… confirming that only the last one is retained.
Not sure why it doesn’t make a functional difference in the end, though. Still good that it seems to work either way, however.
Very good work there. I didn’t check to ensure that both entries were kept, as I was focusing only on the btrfs side of it.
@orangejulio @Flox @Hooverdan
Re:
I’m really not up on the vfs object = btrfs setting/capability but some ‘stuff’/magic works only within a filesystem (btrfs volume): where as the above test spans two btrfs volumes (Pools in Rockstor speak). It may very well be worth testing between two Rockstor shares (btrfs subvolumes) on the same Rockstor Pool (btrfs volume).
Just a thought - I’m a little distracted currently but just wanted to pop that idea into this discussion just in case it helps regarding the effectiveness/scope of this setting.
Hope that helps.
Hi, @phillxnet.
Sorry, I missed your reply to this thread.
Just to clarify, while I did involve 2 separate subvolumes on different pools, only the initial file copy into each subvolume was done across subvolumes. I wanted to use two different disks (one SSD, one HD) to more easily spot if actual file copies were being done. All the suibsequent copy operations were confined to the same folder on each respective drive, so no cross-subvolume copying was done.
Could you please assist me as well as I have the same problem. except I have no idea where you put the Rockstor as I am pretty dumb when it comes to this