Bug 10083 - Sharing the root folder causes "check_reduced_name: logic error"
Summary: Sharing the root folder causes "check_reduced_name: logic error"
Status: NEW
Alias: None
Product: Samba 4.0
Classification: Unclassified
Component: File services (show other bugs)
Version: unspecified
Hardware: All All
: P5 normal (vote)
Target Milestone: ---
Assignee: Samba QA Contact
QA Contact: Samba QA Contact
Depends on:
Reported: 2013-08-13 23:10 UTC by Oussama
Modified: 2019-04-17 04:39 UTC (History)
2 users (show)

See Also:

Example of the Samba log output (32.61 KB, text/plain)
2013-08-13 23:10 UTC, Oussama
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Oussama 2013-08-13 23:10:24 UTC
Created attachment 9131 [details]
Example of the Samba log output

If you share the root directory (/) in your server, Samba will not permit you to browse folders deeper than the root directory. So if I for example try to browse "tmp" folder in the root (/) directory, the samba log output will be:

[2013/08/13 23:44:24.543888,  3] smbd/vfs.c:905(check_reduced_name)
  check_reduced_name [tmp] [/]
[2013/08/13 23:44:24.544152,  2] smbd/vfs.c:1020(check_reduced_name)
  check_reduced_name: logic error (t) in resolved_name: tmp

To make it clear: the above error appears on the Samba server when I try to access the above folder from a Samba client (Windows or Linux).

 The reason is that Samba thinks you are trying to access a symbolic link (bug in vfs.c: line 1247). The if statement that produces the above error is:
if (*p != '/') {
	DEBUG(2, ("check_reduced_name: logic error (%c) "
		"in resolved_name: %s\n",

A temporary solution is to permit following symbolic links using (follow symlinks = yes), in my case it becomes:

I have also attached an example Samba log output
path = /
comment = sysRoot
valid users = server
write list = server
admin users = server
read only = no
available = yes
browseable = yes
writable = yes
guest ok = no
public = yes
printable = no
locking = no
strict locking = no
follow symlinks = yes

Using the above example, the bug appears because the if statement in line 1247 searches for a "/" that separates the "conn_rootdir" directory and the "tmp" folder, but since the "conn_rootdir" is "/" in our case, there is no separating "/" in the path. The whole path (resolved_name) is "/tmp" and thus the *p will point on "t", and thus the test (the if statement) will fail.

But, if the "conn_rootdir" was "/srv/sharedFolder" we would have had an extra appended "/" separating it from the folder name "tmp", like this:
and the *p would have pointed on the "/" (and the test will then pass)

I hope I managed to describe the bug...

To remove the bug, I suggest modifying the if statement like this:

if (*p != '/' && conn_rootdir!='/') {
	DEBUG(2, ("check_reduced_name: logic error (%c) "
		"in resolved_name: %s\n",

Please note that I didn't test the above solution myself, but I think there are no other places to correct in the code that are related to this error.

Thank you
Comment 1 Jeremy Allison 2013-08-14 23:57:20 UTC
I'll take a look at this, but please note sharing out the root directory is a rare use-case :-).


Comment 2 Oussama 2013-08-15 10:53:30 UTC
thank you

Yes you are right :) but my brother uses Windows so he wanted an easy way to access the server root (so he do not need to SSH etc...). It is a home server, otherwise I would have thought more about security.. especially because he has admin rights..
Comment 3 Jeff Morris 2017-03-15 14:22:07 UTC
I realize this is an older bug report, however I just experienced this same problem myself, and searching for a solution led me here. Jeremy mentioned that "sharing of the root directory is a rare use-case". I tend to agree, but I wanted to point out the use-case that led me to this, which I think is a valid one:

In my case, I have a Linux server that is almost completely out of space in the root filesystem. As a sysadmin, I need to analyze the usage of the entire filesystem in order to remedy this. While of course there are many approaches that could be taken to do so, what I would like to do is use a Windows-based utility from a Windows 7 SMB client, specifically WinDirStat, which nicely visualizes filesystem usage graphically. I am not aware of a native Linux utility that offers the same functionality, and since this is a headless server and not running X, even if there is such a utility I would not be able to use it in my situation.

As mentioned in Oussama's initial report, this bug only occurs if follow symlinks is disabled. In my case I can not enable follow symlinks because I have multiple locations in my filesystem where this would result in data duplication, and since the Windows SMB client has no visibility into which directories are or are not symlinks, it has no way to dedupe this, thus throwing off my analysis.

As a workaround, I tried creating a symlink to / named /shared-root and sharing that symlink instead, but unfortunately it resulted in the same behavior (I'm guessing that Samba normalizes symlinks before sharing them, although I haven't actually looked at that part of the code.)

I realize this is a low-priority bug due to how infrequently folks run into it. Again, I just wanted to point out a scenario where having this bug fixed would certainly be useful.

If there's anyway I can help out, please let me know. I'm not much of a C coder, but I'd be happy to assist with testing, etc. 

I've been a Samba user for many, many years, and therefore also wanted to say thanks for all you folks do, so... Thank you! :-)
Comment 4 Kuba Ober 2019-04-16 21:44:01 UTC
Pretty much every glusterfs vfs user expects "path = /" to work, and this error has the potential to be extremely baffling: the result code (NT_STATUS_ACCESS_DENIED) suggests an ACL or permissions issue, while the problem has nothing to do with that: it's just a bug. I had to patch my samba, since I have a few dozen shares all with "path = /", serving gluster volumes.