Messages in this thread | | | From | "Michael H. Warfield" <> | Subject | Re: kernel: SMBFS: need mount version 6 | Date | Sun, 21 Mar 1999 12:42:36 -0500 (EST) |
| |
Claudiu Bosioc enscribed thusly:
[...]
> I did that and it works great, but I thaught I should let you know > that after I smbmount-ed the share it happened that I tried to unmount it > using 'umount /mnt/share' and the computer completely freezed. > all I could do was to change the virtual consoles and use the SysRq keys.
> is there a bug?
I'm not aware of one and I haven't experienced this problem but that certainly doesn't mean there can't possibly be one... :-(
If you ran "umount" as root, everything should have worked just fine. I haven't seen this problem at all. The "smbumount" program is there for non-root users to unmount smb shares that they have previously mounted (it checks with the smbfs module to verify that you are the same id as the original mounter). For root, either should work.
Is this completely reproducible? If so, I need some more information.
What kernel version?
Did you use the smbfs version in the kernel or did you use the module from the smbfs package? (Hint... If you used the one from the smbfs package, stop right now and go back to a virgin kernel tarball. The smbfs package is no longer maintained and is out of date. Destroy that sucker. There is nothing there useful any longer.)
Was smbfs compiled with the Windows 95 bug workaround? (hint... unless you are ONLY mounting Windows 95 shares, you should NEVER enable this option. It doesn't work well with ANY WindowsNT shares.)
What version of Samba? (2.0.3, daily snapshot, or CVS check recommended.)
What is at the other end of the share? (Window 95, Windows 98, Windows NT 4.0, Windows NT 5.0beta2, etc...)
What service packs are installed on the other end? (NT4.0 Service pack 4, etc).
Any "hot fixes" on the other end?
Reason I need the information about the other end is that Micrsoft as "fixed" a pile of stuff that's security or protocol related and, if there is a bug in smbfs, it may depended on what peculiar set of bugs are present at the other end that triggers it. Details matter a lot and may make the difference between reproducing the problem and not.
If someone else can chime in with the procedures we need to follow to dump the kernel and trace it back after a hang like that, we can both learn. :-)
Note... I'm the currently maintainer of smbmount and I'm with the Samba team. I am not currently the maintainer of smbfs, Bill Hawes is, but he doesn't seem to be active on the E-Mail at this time. I've sent in messages to Linus and Bill and spoke face to face with Peter Anvin (they all work at Transmeta) at LinuxWorld about this. Peter said he would talk to Bill and I'm waiting to hear back from them (I need to ding Peter to remind him of this). Linus said that Bill was only doing some routine type maintenance and hadn't intended to do a lot of active maintenance on smbfs. So far, I haven't heard back from Bill.
Sooo... If there is a bug in smbfs itself (which it sounds like it might), it may be outside of my currently tasks, but I'll see what I can do.
> regards, > Claudiu Bosioc
Mike -- Michael H. Warfield | (770) 985-6132 | mhw@WittsEnd.com (The Mad Wizard) | (770) 925-8248 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |