Hi there,
Reading through the change log for the 4.18.1 I noticed some lines that mention a performance drawback.
Anybody else than me saw a 30% performance decrease after samba was upgraded to 4. 18.1? I have to mention that everything is the same (HW, the files copied, source, destination HW, only Samba was upgraded)
The changelog lines I was talking about:
Release Notes for Samba 4.18.0
NEW FEATURES/CHANGES
SMB Server performance improvements
The security improvements in recent releases (4.13, 4.14,
4.15, 4.16), mainly as protection against symlink races,
caused performance regressions for metadata heavy workloads.
While 4.17 already improved the situation quite a lot, with
4.18 the locking overhead for contended path based
operations is reduced by an additional factor of ~ 3
compared to 4.17. It means the throughput of open/close
operations reached the level of 4.12 again.
smbd[12215]: widelinks_warning: Share ‘HDD’ has wide links and SMB1 unix extensions enabled. These parameters are incompatible. Wide links will be disabled for this share.
Checking config files I see that both global configuration file and smb.conf contains wide links
, and no entry for SMB1 or NT1 protocol - so I have no idea why I get warning for SMB1 being activated!
The changelog lines you showed are for 4.18.0 but Samba was changed from version 4.17.5 in Core Update 174 to version 4.18.1 in Core Update 175.
In Core Update 172 the samba version was 4.17.3 was introduced.
The Samba WUI page sets wide links = yes in the conf file.
Looking at the smb.conf man page it has the default smb1 unix extensions = yes
If smb1 unix extensions = yes and wide links = yes then samba automatically disables wide links. This is a security feature as wide links allow you to follow symlinks within the share directory tree but if smb1 unix extensions is allowed then those sysmlinks can be followed outside of the share directory tree.
I suspect that some time in the past the smb1 unix extensions default was changed.
I will look at doing a change to the IPFire smb.conf settings to have smb1 unix extensions = no
This will then allow wide links = yes to stay active within the share directory tree.
By default smb1 is not enabled on the IPFire Samba server so changing the smb1 unix extensions to not be allowed won’t have any impact. Most clients should not be trying to negotiate SMB1.
I don’t use Samba on IPFire . On my PC systems I only use it on one machine to provide a share for my printer to send any scanned pages too.
That activity is quite low on file sizes and so speed reductions aren’t really noticeable.
If the problem is related to the security improvements that Samba have made then the only option will be to wait for the performance improvements to be recovered while maintaining the security benefits.
There is already a patch for an update to samba-4.18.4 and there are CVE fixes in Samab for the versions between 4.18.1 and 4.18.4. There is now a new samba version of 4.18.5 that has more CVE fixes so that will also get merged I would expect before Core Update 177 is released.
After reading through various samba documents and going back to the smb.conf man page in more detail, I have realised that following symlinks that are within the directory tree that is being exported are always allowed to be followed.
What wide links allows to happen is to follow a symlink in the directory tree to be shared that points to a file that is outside the shared directory tree.
So if in the directory tree /home/user/fred/ there is a symlink that points to a file in /etc/ then wide links will allow the user accessing the share to be able to follow that symlink and access that file.
If smb1 unix extensions is enabled then the client user would be able to create new symlinks to files that are outside the shared directory tree.
For example a user on the client could create a symlink in the shared directory tree to point to /etc/fstab
Once that symlink has been created then that user could go in and edit that symlinked file. The only limiter is the user on the client knowing the files that are available outside of the shared directory tree.
That is why when smb1 unix extensions is enabled then wide links is automatically disabled.
So in the current samba setup wide links is always disabled as smb1 unix extensions default setting is yes. This has been the case for around three years. wide links or unix extensions were able to be selected on the WUI prior to that time.
As we have been living without the ability to follow symlinks outside of the shared directory tree for those three years it seems better to me to remove the wide links = yes entry from the samba.cgi code as that means that all files being shared via samba on IPFire must be within the shared directory tree. That seems the more secure way of doing things on a firewall if a file server system is going to be used on it. It will also be following what has been the de facto situation for three years anyway.
EDIT:
Have confirmed that the default for unix extensions was yes, three years ago when the above change to the samba.cgi was made. So my conclusion to remove the wide links is correct. It will change nothing and will stop the warning messages about wide links being disabled, found by @hjkl
Hello @bonnietwin / Adolf,
Much appreciated the detailed answer!
I have manually disabled wide links (editing both global configuration file and smb.conf file).
One clarification if I may: I did not found (via grep) any smb1 inside Samba config files (no matter if those are global or smb.conf).
Therefore I am a bit confused when you say
How do I turn off smb1?
All my clients are Windows 10 or Linux / Ipfire so I do not need smb1 at all.
The default value (if not explicitly specified) for the server min protocol is smb2_02 and server max protocol is smb3
So by default smb1 protocol on the server (IPFire) is disabled.
smb1 unix extensions is a set of extensions to be used with smb1 if the protocol is enabled.
So by default the smb1 unix extensions are enabled but as, by default, the smb1 protocol is disabled they will never be used with the default settings.
If any setting is not explicitly specified in smb.conf then the default value for that setting is used by samba.
Just saw your late edit.
The line UNIXEXTENSION=off is a variable assignment that used to be used in the samba.cgi code. The change 3 years ago removed the use of the variable UNIXEXTENSION so the value in the settings file is not used.
Have you used samba for at least the last 3 years. If yes then that variable may be left there from when it used to be used and the settings file would also be saved as part of the backup. I suspect that variable would not be in the settings file with a more recent install.
I will check the samba setup I have for testing purposes on one of my vm test bed networks later today or tomorrow to confirm, or otherwise, my conclusion.
Summary. Don’t worry. If smb1 is not mentioned in the smb.conf file then by default smb1 protocol is not being used on the server.
EDIT:
I checked back on the code changes 3 years ago and the SMB2=on line in the settings file is also no longer used since then.
Previously if you set SMB2=on in the WUI page then it added the line server max protocol = smb2 into the smb.conf which meant that the client would only get smb2 even if it could use smb3.
The current status is that the server can work with smb2 or smb3 and will use smb3 if the client can work with it. If not then it will work with smb2.
I am pretty confident that those two parameters in the settings file are not used anymore, so they are redundant.
EDIT2:
Have checked my samba settings file on my vm testbed and that does not have the UNIXEXTENSION or SMB2 entries present. To me that confirms that those two values are redundant setting values that used to be used when there were more settings available to be defined in the samba.cgi WUI page. Leaving them in the settings file won’t cause a problem because in the present code version those values will be ignored.
Thank you again,
Yes, that Samba machine started with core around 100 (I can’t remember when I have build it exactly).
So definitely that Samba is in use for more than 3 years…
After setting wide links = no no more warning messages & combined with the fact that SMB1 is turned off by default I believe nothing more for me to do (I am not going to clean the settings as I do not have the knowledge to check each line if is in use by .cgi or not).
I guess I have to wait for the next version of samba to see if the speed gets back to what I had in 4.17.3 (part of core 172 that I was running before doing upgrade to core 176)
I thought that before I look at doing a patch for this issue I should reproduce it on my samba server on my vm testbed. However I have looked in my logs for nmbd and smbd and have not found any message related to wide links as you found.
Reading this again, I realised that what it is saying is that smbd has found a symlink on your share HDD which is a wide link, ie linking to a file outside of the share directory tree.
So on my share I created a symlink that points to /etc/fstab which is outside the exported directory tree of /mnt/share1
However, having created that symlink and restarting samba, I still do not see any warning about wide links being disabled.
So at the moment I have not been able to reproduce the warning message that you got.
Can you provide copies of the smb.conf file and a screenshot of your samba WUI page with the Share section opened for editing. Redact anything that has privacy concerns for you.
Appreciate it if you are able to help with this.
EDIT:
Don’t worry about this anymore. I have been able to reproduce it. I did not have the share mounted on a client and that warning message about the wide links and smb1 unix extensions conflict only occurs when the share has been mounted on a client.
As mentioned in the previous post this warning message
means that you have at least one symlink in your HDD share which points outside of the directory tree defined by HDD.
With wide links being disabled by the above warning message or removing the wide links = yes line from smb.conf means that your client that has the HDD share mounted will not even see the symlinked file on the HDD share.
As smb1 is not being used by default the more sensible approach is to leave wide links = yes in smb.conf and to add smb1 unix extensions = no directly after it. This will then prevent the warning message and allow you to see any symlinked files that are wide (ie outside the directory tree)
I have confirmed that this works on my vm testbed system and will raise a bug on this issue and submit a patch to make smb1 unix extensions = no