The debug message you highlighted below is a good clue. I'll start working on this and get back to you.
Afshin Jean-Noel Filippi wrote: > I enabled debugging on the syslog daemon to get more information. > Here are the errors thrown while SMB stops working: > > Oct 3 22:31:00 vdcnas001 idmap[4619]: [ID 537588 daemon.debug] Found > _ldap._tcp.gc._msdcs.photochannel.local 600 IN SRV [0][100] > ad001.photochannel.local:3268 > Oct 3 22:31:00 vdcnas001 idmap[4619]: [ID 966149 daemon.debug] unable > to discover Site Name > Oct 3 22:31:00 vdcnas001 idmap[4619]: [ID 873961 daemon.info] change > domain_controller=ad001.photochannel.local port=389 > Oct 3 22:31:00 vdcnas001 idmap[4619]: [ID 873961 daemon.info] change > domain_controller=vdcdc002.photochannel.local port=389 > Oct 3 22:31:49 vdcnas001 smbd[10584]: [ID 775558 daemon.debug] > smb_door_srv_func: execute server routine(opcode=0) > Oct 3 22:31:49 vdcnas001 smbd[10584]: [ID 277356 daemon.debug] > *smbrdr_netuse_alloc: table full* > Oct 3 22:31:49 vdcnas001 smbd[10584]: [ID 577104 daemon.debug] > smbrdr_tree_connect: init failed > Oct 3 22:31:49 vdcnas001 smbd[10584]: [ID 321293 daemon.debug] smbrdr: > (open) vdcdc002 PHOTOCHANNEL VDCNAS001$ \NETLOGON INTERNAL_ERROR > Oct 3 22:31:50 vdcnas001 smbd[10584]: [ID 775558 daemon.debug] > smb_door_srv_func: execute server routine(opcode=0) > Oct 3 22:31:50 vdcnas001 smbd[10584]: [ID 277356 daemon.debug] > smbrdr_netuse_alloc: table full > Oct 3 22:31:50 vdcnas001 smbd[10584]: [ID 577104 daemon.debug] > smbrdr_tree_connect: init failed > > > ------------------------------------------------------------------------ > *From:* Jean-Noel Filippi > *Sent:* Fri 03/10/2008 6:22 PM > *To:* Nicolas Williams > *Cc:* [EMAIL PROTECTED]; [email protected] > *Subject:* Re: [cifs-discuss] Idmap stability problem > > The ouput was created when the issue was happening. I attempted to connect to > the share 2 or 3 times from a Windows host. Each time I got permission denied. > > To answer your other questions, restart SMB alone fixed the problem. I don't > need to restart idmap. You are right and I should be troubleshotting SMB > instead of idmap. Is there any dtrace script to run to catch SMB traffic > while the issue is happening? > > Thanks, > > JN > > ________________________________ > > From: Nicolas Williams [mailto:[EMAIL PROTECTED] > Sent: Fri 03/10/2008 1:29 PM > To: Jean-Noel Filippi > Cc: [EMAIL PROTECTED]; [email protected] > Subject: Re: [cifs-discuss] Idmap stability problem > > > > On Fri, Oct 03, 2008 at 12:38:50PM -0700, Jean-Noel Filippi wrote: >> We are still struggling here with the SMB and IDMAP daemons. >> For some reasons, all the authentications requests start failing >> randomly. The only way to get it working again is to restart SMB. >> >> I have attached the output of the dtrace script for idmap (captured >> while authencation was failing) and the cifs-gendiag output. >> >> I would appreciate any help. > > Hmmm, I'm not finding any telltale clue in there. I'll have to look at > it more carefully. > > Meanwhile, the idmap.d output is particularly small. When run on a busy > service, or even on an otherwise idel service just to capture a single > logon attempt this script tends to produce massive output. Can you > confirm that the output you sent captures the failing share logon? > > Nico > -- > > > _______________________________________________ > cifs-discuss mailing list > [email protected] > http://mail.opensolaris.org/mailman/listinfo/cifs-discuss _______________________________________________ cifs-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
