(Posting this bug, as described in samba-technical at request of jra.) Simple explanation: Samba 3.0.4 and a Dfs root. One link. Windows XP client. The Dfs link redirects fine when connecting to the server in a way that uses NTLM auth. The Dfs link does not redirect and gives error when connecting to the server in a way that uses Kerberos auth. Here is the critical point of the failure in the logfile for the Kerberos case (audioj is the name of the symlink): [2004/05/24 17:54:07, 3, pid=27889] smbd/trans2.c:call_trans2qfilepathinfo(2353) call_trans2qfilepathinfo: SMB_VFS_STAT of audioj failed (No such file or directory) [2004/05/24 17:54:07, 10, pid=27889] smbd/trans2.c:set_bad_path_error(2213) set_bad_path_error: err = 2 bad_path = 0 [2004/05/24 17:54:07, 3, pid=27889] smbd/error.c:error_packet(94) error string = No such file or directory Maybe everything above gives somebody a clue what's up. Beyond here I'm speculating... I studied smbd/trans2.c and see differences between get_lanman2_dir_entry() and call_trans2qfilepathinfo(). I assume these have similar functions for different protocol versions. In get_lanman2_dir_entry(): (Success case) } else if (SMB_VFS_STAT(conn,pathreal,&sbuf) != 0) { /* Needed to show the msdfs symlinks as directories */ if(lp_host_msdfs() && lp_msdfs_root(SNUM(conn)) && is_msdfs_link(conn, pathreal, NULL, NULL, &sbuf)) { DEBUG(5,("get_lanman2_dir_entry: Masquerading msdfs link %s as a directory\n", pathreal)); } In call_trans2qfilepathinfo(): (Failure case) } else if (!VALID_STAT(sbuf) && SMB_VFS_STAT(conn,fname, &sbuf)) { DEBUG(3,("call_trans2qfilepathinfo: SMB_VFS_STAT of %s failed (%s)\n",fname,strerror(errno))); return set_bad_path_error(errno, bad_path, outbuf, ERRDOS,ERRbadpath); } The the call_trans2qfilepathinfo() case, that's the error I get. On the surface it seems that it just needs some of the msdfs tests that the get_lanman2_dir_entry() function has. Am I close? Maybe I'm way off. Of course I can provide full log files if it's helpful. I can also enter in bugzilla but was lacking a concise description of the bug. --Eric
Created attachment 529 [details] Debug level 10 of failure case The service \\canon.cac.washington.edu\nebulahome is a dfs root. It contains one link: myhome -> msdfs:kodak5.cac.washington.edu\homes When connecting in a way that uses kerberos auth not ntlm then msdfs link does not work, and an error is reported.
Created attachment 530 [details] Debug level 10 of success case The service \\canon.cac.washington.edu\nebulahome is a dfs root. It contains one link: myhome -> msdfs:kodak5.cac.washington.edu\homes In order to avoid using kerberos auth and force samba to fall back to NTLM I connect to the IP rather than the FQDN/Service Principal Name using this: \\140.142.15.168\nebulahome\myhome. When connecting using this method that uses NTLM the msdfs link expands and I reach the target.
I need some more info about your setup. Is the kerberos server a Win2kx AD server ? Do you have winbind setup on the Samba server ? What seems to be happening in the trace is the WinXP machine is attempting to log on with a machine id krb5 ticket in order to read the dfs link info (ie. it wants to log on with a machine id to the IPC$ pipe - but we don't see that as we only see the sessionsetup getting rejected). Without this logon the XP client fails to read the dfl link info and thus the redirect is rejected. I think this might work if winbindd were running correctly, as the client username may be mapped into a UNIX username and the logon should succeed, although I';; be honest and say I haven't tested this myself. Jeremy.
> I need some more info about your setup. Is the kerberos server a Win2kx AD > server ? Yes. Do you need more info than that? A smb.conf or more description? > Do you have winbind setup on the Samba server ? No. > What seems to be happening in the trace is the WinXP machine is attempting to > log on with a machine id krb5 ticket in order to read the dfs link info (ie. it > wants to log on with a machine id to the IPC$ pipe - but we don't see that as we > only see the sessionsetup getting rejected). Without this logon the XP client > fails to read the dfl link info and thus the redirect is rejected. I understand what you're saying but I'm not sure it makes sense. Why would I be able to see the Dfs link but not follow it? Using the example from the traces I sent for example, I can connect to \\canon.cac.washington.edu\nebulahome and see the link 'myhome' masqueraded as a directory folder. Here it is at the command line: H:\>dir \\canon.cac.washington.edu\nebulahome Volume in drive \\canon.cac.washington.edu\nebulahome is nebulahome Volume Serial Number is 0481-82E5 Directory of \\canon.cac.washington.edu\nebulahome 06/07/2004 03:27 PM <DIR> . 05/31/2004 08:20 PM <DIR> .. 05/29/2004 10:05 PM <DIR> myhome 0 File(s) 0 bytes 3 Dir(s) 730,726,400 bytes free Using your theory does it make sense that I can connect and see the link but not be able to redirect to it or see the DFS property tab? That seems really odd to me that I can authenticate enough to see it but not enough to redirect. > I think this might work if winbindd were running correctly, as the client > username may be mapped into a UNIX username and the logon should succeed, > although I';; be honest and say I haven't tested this myself. So if winbindd were running the machine id in question, kleenex_q$, would be mapped to some UNIX username and it would work? I don't understand what UNIX username it would map to. I'm not familiar with how machine id's are mapped to UNIX users. --Eric
still an issue in 3.0.11 ? If so please reopen.
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.
Exactly what was the fix ? Which version ? I downloaded 3.0.22 and am having the same problem. AD 2003 (no winbind). rajeev
Please open a new report if you believe there is still a source bug. You can refer to this report. But adding comments to a bug that's been closed for a year will get ignored. If you think it may be a configuration problem, please email the samba@samba.org ml.