This bug is several years old. Just now decided to send it in. It happens with 3.5 3.4 ...etc... as well. After setting up smbd to start via inetd (as a service) it will fail to fire off a process when you try to log in. We tracked it down to the following and installed this patch to fix it: *** smbd/server.c.orig Fri Mar 9 16:51:17 2012 --- smbd/server.c Fri Mar 9 16:51:34 2012 *************** *** 1069,1074 **** --- 1069,1075 ---- /* Init the security context and global current_user */ init_sec_ctx(); + setpgrp(); if (smbd_messaging_context() == NULL) exit(1); It runs fine after that. I just tested it with 3.6.9 and if I take the patch out it still fails miserably. Happy after the patch. Here is our install script to run samba via inetd as a service if that makes any difference: # Setup for temporary files INETFILE=/tmp/samba.inet DESTDIR=/tmp XMLFILE_SMB139=/tmp/netbios-ssn-tcp.xml XMLFILE_SMB445=/tmp/microsoft-ds-tcp.xml XMLFILE_NMB=/tmp/netbios-ns-udp.xml trap 'rm -f $INETFILE $XMLFILE_SMB139 $XMLFILE_SMB445 $XMLFILE_NMB' 0 1 2 15 # Add smbd service for port 139 cat >$INETFILE <<'XXX' netbios-ssn stream tcp nowait root /opt/samba/current/sbin/smbd smbd XXX /usr/sbin/inetconv -n -i $INETFILE -o $DESTDIR >/dev/null /usr/sbin/svccfg import $XMLFILE_SMB139 # Add smbd service for port 445 cat >$INETFILE <<'XXX' microsoft-ds stream tcp nowait root /opt/samba/current/sbin/smbd smbd XXX /usr/sbin/inetconv -n -i $INETFILE -o $DESTDIR >/dev/null /usr/sbin/svccfg import $XMLFILE_SMB445 # Add nmbd service cat >$INETFILE <<'XXX' netbios-ns dgram udp wait root /opt/samba/current/sbin/nmbd nmbd XXX /usr/sbin/inetconv -n -i $INETFILE -o $DESTDIR >/dev/null /usr/sbin/svccfg import $XMLFILE_NMB We only use Samba for CIFS shares. We do not use it for authentication or AD services. Here is a standard base smb.conf we would use: [global] workgroup = ECN server string = ECN fileserver - pier smb passwd file = /etc/smbpasswd passdb backend = smbpasswd log level = 1 max log size = 0 unix extensions = No deadtime = 10 load printers = No printcap name = /dev/null local master = No wins server = XXX.XXX.XXX.XXX remote announce = XXX.XXX.XXX.XXX remote browse sync = XXX.XXX.XXX.XXX use sendfile = Yes getwd cache = Yes max protocol = SMB2 map untrusted to domain = Yes name resolve order = host wins bcast nt acl support = No veto oplock files = /*.xls/ wide links = Yes -mike
Looks like the wrong place to me. Did you try using setsid() inside this part of the code ? (in source3/smbd/server.c): 1266 if (!is_daemon) { 1267 /* inetd mode */ 1268 TALLOC_FREE(frame); 1269 1270 /* Started from inetd. fd 0 is the socket. */ 1271 /* We will abort gracefully when the client or remote system 1272 goes away */ 1273 smbd_set_server_fd(dup(0)); 1274 1275 /* close our standard file descriptors */ 1276 close_low_fds(False); /* Don't close stderr */ 1277 1278 #ifdef HAVE_ATEXIT 1279 atexit(killkids); 1280 #endif 1281 1282 /* Stop zombies */ 1283 smbd_setup_sig_chld_handler(); 1284 1285 smbd_process(smbd_server_conn); 1286 1287 exit_server_cleanly(NULL); 1288 return(0); 1289 } Although it's been a long time since we ever tested smbd under inetd mode. I wouldn't be surprised if many things broke in this mode. Jeremy.
(In reply to comment #1) > > Although it's been a long time since we ever tested smbd under inetd mode. I > wouldn't be surprised if many things broke in this mode. > > Jeremy. Its been too long ago that we worked on this. I just don't recall. I would be glad to test anything if you think thats the way to go (it fails almost immediately for me on my test machine). With 3.6 we are seeing some wierd errors. Two users associated with the same PID via smbstatus for example. We haven't tracked it down yet but I have wonder if its related now. I guess we could go back to daemon mode if you think thats cleaner/more bug free. Memory is plentiful now although we really like being able to update the software and not have to kill existing sessions off.
(In reply to comment #2) > (In reply to comment #1) > Its been too long ago that we worked on this. I just don't recall. I would be > glad to test anything if you think thats the way to go (it fails almost > immediately for me on my test machine). With 3.6 we are seeing some wierd > errors. Two users associated with the same PID via smbstatus for example. We > haven't tracked it down yet but I have wonder if its related now. I guess we > could go back to daemon mode if you think thats cleaner/more bug free. Memory > is plentiful now although we really like being able to update the software and > not have to kill existing sessions off. ... I can just hope that you run the two different versions on two different lock paths for independent tdb's....
(In reply to comment #1) > Looks like the wrong place to me. > > Did you try using setsid() inside this part of the code ? (in > source3/smbd/server.c): > So far, my brief testing shows this to work. That basically means inetd didn't blow up and the share mounted. Still trying a few things. Note I haven't had my coffee yet. --mike
setups with smbd started via inetd had been deprecated and are no longer supported. smbd ahould run in daemon mode.