Bug 12539 - Samba 4.5+ Browsing DFS share get NT_STATUS_OBJECT_NAME_INVALID
Summary: Samba 4.5+ Browsing DFS share get NT_STATUS_OBJECT_NAME_INVALID
Status: RESOLVED FIXED
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: Other (show other bugs)
Version: 4.5.3
Hardware: All All
: P5 major (vote)
Target Milestone: ---
Assignee: Andrew Bartlett
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-01-25 12:12 UTC by Romain MARIADASSOU
Modified: 2017-09-30 01:05 UTC (History)
4 users (show)

See Also:


Attachments
Trace of network traffic requesting DFS root (7.15 KB, application/octet-stream)
2017-02-14 17:44 UTC, Engel, Johannes
no flags Details
Debug log of Samba DC (1.13 MB, text/plain)
2017-02-14 17:52 UTC, Engel, Johannes
no flags Details
patch for master (1.02 KB, patch)
2017-09-26 16:17 UTC, Noel Power
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Romain MARIADASSOU 2017-01-25 12:12:06 UTC
Browsing a DFS share hosted in a Samba 4.5.3 / 4.5.4 server generate NT_STATUS_OBJECT_NAME_INVALID

The same apply with a Windows Server 2003 as a client to a Samba 4.5.3 / 4.5.4 server
It's OK with a Windows Server 2008R2 as a client.

Command used (samba 4.5.4 client) to browse a Samba 4.5.3 / 4.5.4 DFS server :
/usr/local/samba/bin/smbclient //champdumoulin/documents -U administrateur@mydomain.loc%PASSWORD -c 'ls'

Result : 
[root@venus ~]# /usr/local/samba/bin/smbclient //champdumoulin/documents -U administrateur@mydomain.loc%PASSWORD -c 'ls'
Domain=[MYDOMAIN] OS=[Windows 6.1] Server=[Samba 4.5.4]
NT_STATUS_OBJECT_NAME_INVALID listing \champdumoulin\documents\*


Share on samba server :
[documents]
        comment         = Les documents
        path            = /home/samba/documents
        browseable      = yes
        writable        = yes
        public          = yes
        create mask     = 2775
        directory mask  = 2775
        msdfs root      = yes
        inherit acls    = yes
        inherit owner   = yes
        inherit permissions = yes
        veto files      = /.SyncTrash/.SyncID/.SyncIgnore/*.!sync/.sync/.stfolder/
        hide files      = /desktop.ini/Thumbs.db/~$*/.SyncTrash/.SyncArchive/.SyncID/.SyncIgnore/*.!sync/*.SyncPart/*.SyncTemp/.sync/
        follow symlinks = yes
        wide links      = yes
        vfs objects     = shadow_copy2
        shadow:snapdir  = /home/samba/shadow
        shadow:basedir  = /home/samba
        shadow:format   = %Y-%m-%d
        shadow:localtime = no
        shadow:sort     = desc


This share worked in a Samba Server 4.4.
Comment 1 Aurélien Aptel 2017-01-27 09:18:37 UTC
Hi Romain,

Could you provide a network capture of that command for both samba version (4.4 and 4.5.4) along with full debug output of both the client and the server?

We have a wiki page if you are unfamiliar with how to make a network capture https://wiki.samba.org/index.php/Capture_Packets

As for the logging:
- smbclient: use -d10
- smbd: add the following to the [global] section of your smb.conf:

  logging = file
  # directory must already exist
  log file = /tmp/debug/debuglog.%I
  log level = 10

You should get a log file per IP, you can archive the directory and send it here.
Also try to empty the log dir between tests.
Comment 2 Engel, Johannes 2017-02-14 17:44:29 UTC
Created attachment 12926 [details]
Trace of network traffic requesting DFS root
Comment 3 Engel, Johannes 2017-02-14 17:52:35 UTC
Created attachment 12927 [details]
Debug log of Samba DC
Comment 4 Engel, Johannes 2017-03-06 17:17:58 UTC
Hi Team,
is there anything else I could provide to help sort out this issue? THX!
Comment 5 Alban Rodriguez 2017-04-06 08:16:29 UTC
Hello,

I also confirm this issue.
Since we upgraded to branch 4.5 (4.5.8), our web access to Samba dfs root share (which uses jcifs library) does not work anymore.
If I downgrade to branch 4.4 (4.4.13), it works again.
It only affects dfs root shares, not regular shares.

No problem with recent Windows/Mac clients but I also confirm it doesn't work with smbclient v 4.5.8 either.
In both cases (jcifs and smbclient), the SMB protocol used is NT1 while recent Windows/Mac clients are using SMB3+

I tried to enable ntlm auth which was a defaulted to no from 4.5.0 but it does not resolve the issue.

Thanks

Alban
Comment 6 Alban Rodriguez 2017-04-06 08:29:45 UTC
In fact, only enumerating content using wildcard '*' seems to cause the issue:

smbclient -U "UNIV-LR\\arodrigu" //Samba/DocumentsCommuns
Domain=[UNIV-LR] OS=[Windows 6.1] Server=[Samba 4.5.7]
smb: \> ls
NT_STATUS_OBJECT_NAME_INVALID listing \Samba\DocumentsCommuns\*

smb: \> ls pipo
  pipo                                D        0  Thu Apr  6 10:00:16 2017

		9418752 blocks of size 1024. 1439132 blocks available

smb: \> ls test
  .                                   D        0  Mon Mar 27 10:41:13 2017
  ..                                  D        0  Tue Apr  4 12:11:05 2017
  .DS_Store                           H     6148  Mon Mar 27 10:51:42 2017
  AAA                                 D        0  Mon Mar 27 10:52:22 2017

		9418752 blocks of size 1024. 1439124 blocks available

(test is a dfs link)

In server log:
[2017/04/06 10:29:08.829042,  3] ../source3/smbd/trans2.c:2618(call_trans2findfirst)
  call_trans2findfirst: dirtype = 16, maxentries = 1366, close_after_first=0, close_if_end = 1 requires_resume_key = 1 backup_priv = 0 level = 0x104, max_data_bytes = 65535
[2017/04/06 10:29:08.829135,  5] ../source3/smbd/filename.c:443(unix_convert)
  unix_convert called on file "*"
[2017/04/06 10:29:08.829207,  3] ../source3/smbd/error.c:82(error_packet_set)
  NT error packet at ../source3/smbd/trans2.c(2702) cmd=50 (SMBtrans2) NT_STATUS_OBJECT_NAME_INVALID
Comment 7 Noel Power 2017-09-26 16:17:39 UTC
Created attachment 13631 [details]
patch for master

This patch seems to fix the bug for me, seems a bool is being passed instead of the actual flags value
Comment 8 Romain MARIADASSOU 2017-09-28 23:02:03 UTC
Patch seems OK for me too.

Samba version 4.7.0 seems to work too.
Comment 9 Jeremy Allison 2017-09-30 01:05:34 UTC
Noel, do we need a back-port for 4.6.next for this ?

Jeremy.