Dear Admin, I wish to report a problem that I have been experiencing with Samba versions 2.0.6 and 2.7. The specific problem concerns mounting windows shares on our Linux machines running Linux 6.2. These shares are mounted using the mount -t smbfs command. These shares keep on disappearing ( i.e. they time out) and needs to be remounted everyday. I have checked all the user rights on both machines and they are all okay. Find below the commands used to mount these shares. We also use encrypted passwords in the smb.conf file ( encrypted passwords = yes), and tested this file with the testparm command and there is no error. username on Linux and NT4 machines = linux6user user password = L6Nt4useR shares on NT4 = //nt4pc-0001/usershares mount point on Linux machines = /home/public/nt4shares mount command mount -t smbfs //nt4pc-0001/usershares -o username=linux6user%L6Nt4useR Entry in the /etc/fstab file # windows shares mounted on Linux 6.2 on mount point /home/public/nt4shares //nt4pc-0001/usershares /home/public/nt4shares smbfs password=L6Nt4useR 0 0 I look forward to hearing from you at your very earliest convenience. yours sincerely, Winston
Winston Nchamukong wrote:> > Dear Admin,I don't think there's anyone called 'Admin' here. Welcome to anarchy. ;-)> > I wish to report a problem that I have been experiencing with Samba versions > 2.0.6 and 2.7. The specific problem concerns mounting windows shares on our > Linux machines running Linux 6.2.There's really no such thing. RedHat 6.2 by any chance? There's a MacMillan product with similar numbering as well.> These shares are mounted using the mount > -t smbfs command. These shares keep on disappearing ( i.e. they time out) >There definitely is a bug in smbmount that relates to dying mounts. I found a patch on DejaNews, but can't remember now who posted it. To apply it, I had to modify /usr/src/linux/proc.c and rebuild the kernel. I hope someone else has a more definitive answer as to when this might be incorporated in smbfs, or even as to where this patch originated. I believe there was a little more code to the patch I saw, but for whatever reason I judged it unecessary in my case. Here's an excerpt from my proc.c: /* * Wait for the new connection. */ // KGM 10/6/2000 // Here I applied some code that I saw on DejaNews to get rid of // my problems with a mount process dying. The following commented code // is the original. //interruptible_sleep_on_timeout(&server->wait, 5*HZ); //if (signal_pending(current)) // printk("smb_retry: caught signal\n") printk("smb_retry: Doing sleep_on_timeout due to patch\n"); sleep_on_timeout(&server->wait, 5*HZ); (To be ticky about it, that probably should be: #ifdef SMBFS_DEBUG_VERBOSE printk("smb_retry: Doing sleep_on_timeout due to patch\n"); #endif since the sleep_on_timeout is a common, normal thing and otherwise you'll see a lot of those in your logs.) If you're seeing that 'smb_retry: caught signal' in your logs, this is most certainly the problem you're suffering from. Things are working dandy for me since I applied it. I have to think a lot of folks don't leave Windows shares mounted very long, or more would be seeing this problem. Then there are the many who don't use smbfs at all.
On Thu, 4 Jan 2001, Winston Nchamukong wrote:> I wish to report a problem that I have been experiencing with Samba versions > 2.0.6 and 2.7. The specific problem concerns mounting windows shares on our > Linux machines running Linux 6.2. These shares are mounted using the mountRedHat 6.2? with kernel 2.2.12 or so? You should upgrade to 2.2.18, it works around a common problem where signals are causing smbfs mounts to become unusable. Kernels earlier than 2.2.17 have nasty machine-crashing (possibly even data corrupting) bugs in smbfs (you need to try a bit to trigger them, but they are definitly there). Even so, 2.2.18 isn't really ok. At least one person have reported that multithreaded programs run under gdb or strace will cause smbmount to fail. If you try 2.2.18 and still see problems, try adding this patch. (It's a better fix than what's in 2.2.18, except that it disables SIGKILL so it _may_ be possible to get programs to hang and not be able to kill them ...) This is a very common problem, I suspect you have lines like this in your syslog files: smb_retry: caught signal /Urban --- linux-2.2.18-orig/fs/smbfs/sock.c Wed Dec 13 21:27:44 2000 +++ linux/fs/smbfs/sock.c Tue Jan 2 21:19:03 2001 @@ -30,11 +30,13 @@ static int _recvfrom(struct socket *socket, unsigned char *ubuf, int size, - unsigned flags) + unsigned rflags) { struct iovec iov; struct msghdr msg; struct scm_cookie scm; + sigset_t old_set; + unsigned long flags; msg.msg_name = NULL; msg.msg_namelen = 0; @@ -43,11 +45,33 @@ msg.msg_control = NULL; iov.iov_base = ubuf; iov.iov_len = size; - + memset(&scm, 0,sizeof(scm)); - size=socket->ops->recvmsg(socket, &msg, size, flags, &scm); - if(size>=0) - scm_recv(socket,&msg,&scm,flags); + + /* + * block all signals to avoid -ERESTARTSYS problem in recvmsg + * + * FIXME: changing the signal mask is done elsewhere too. + * This code removes the ability to SIGKILL a process that has hung in + * recvmsg (does it? I'm guessing ...). + * Use poll/timeout to ensure progress? + */ + spin_lock_irqsave(¤t->sigmask_lock, flags); + old_set = current->blocked; + siginitsetinv(¤t->blocked, 0); + recalc_sigpending(current); + spin_unlock_irqrestore(¤t->sigmask_lock, flags); + + size = socket->ops->recvmsg(socket, &msg, size, rflags, &scm); + if (size >= 0) + scm_recv(socket, &msg, &scm, rflags); + + /* restore old signal mask */ + spin_lock_irqsave(¤t->sigmask_lock, flags); + current->blocked = old_set; + recalc_sigpending(current); + spin_unlock_irqrestore(¤t->sigmask_lock, flags); + return size; } @@ -529,7 +553,7 @@ buf_len = server->packet_size; buf_len = smb_round_length(buf_len); if (buf_len > SMB_MAX_PACKET_SIZE) - goto out_no_mem; + goto out_too_long; rcv_buf = smb_vmalloc(buf_len); if (!rcv_buf)