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", *p, fname)); SAFE_FREE(resolved_name); return NT_STATUS_ACCESS_DENIED; } 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 [sysRoot] 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: "/srv/sharedFolder/tmp" 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", *p, fname)); SAFE_FREE(resolved_name); return NT_STATUS_ACCESS_DENIED; } 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
I'll take a look at this, but please note sharing out the root directory is a rare use-case :-). Cheers, Jeremy.
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..
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! :-)
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.