-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I have been testing a whole lot of these issues, and the only one I can
reproduce it the rpcclient> enumdrivers not returning a list of the
installed print drivers (not critical, print driver uploading still works).

We run samba as a domain controller (2.2.3a-1mdk on Mandrake 8.0) in
production for a 60-user domain. We have a Mandrake 8.1 box running
samba-2.2.3a-6mdk as a production print server, with point-and-print
drivers, no problems from any of our Windows NT SP6a or Windows 2000 SP2
clients running Office 2000, OpenOffice build 641c etc.

Please note that we have applied the only two suggested patches to
samba-2.2.3a, being a trivial patch to the samba LDAP schema file, and a
patch to supposedly fix a race when querying printers (which I haven't
seen).



Gerald Drouillard wrote:
| There has been a lot of activity on fixing 2.2.3a on the samba CVS log
since
| 3a was released.  Changed have slowed in the last day or two, so maybe
Samba
| is close to a 2.2.3b release.  I hope the Samba Crew can get a new version
| out before the final Mandrake 8.2.  I have been using 2.2.3a with only a
| couple annoyances:
| -slow printing for win2k

Works for me. Slow compared to?

| -needed to add everyone to the group adm so that they could log in.

This must be something with your setup. The adm group is not compiled in
anywhere, so it can only be an issue with some permissions you have set,
or some of the group parameters in your smb.conf file.

If you want to try and resolve this, can you please send me your
smb.conf file, and confirm that normal users have write access to the
profiles directory, and read access to the netlogon directory.

|
|
|>-----Original Message-----
|>From: [EMAIL PROTECTED]
|>[mailto:[EMAIL PROTECTED]]On Behalf Of Brad Felmey
|>Sent: Tuesday, March 05, 2002 1:48 PM
|>To: [EMAIL PROTECTED]
|>Subject: Re: [Cooker] samba-2.2.3a-6mdk and hung mountpoints
|>
|>
|>On Tue, 2002-03-05 at 11:30, Buchan Milne wrote:
|>
|>
|>>Brad Felmey wrote:
|>>
|>>>-Uvh'ing to this build is causing smb mountpoints to hang permanently.
|>>>I've verified this on seven separate machines so far. If a share is
|>>>mounted via smbmount, and anything happens to that mount (network drop
|>>>or whatever) during access. That mountpoint hangs _forever_. It's
|>>>impossible to kill it with 'kill -9'. It's as bad as NFS. It used to
|>>>time out and give up after a while, and you could certainly
|>>>
|>kill it, but
|>
|>>>this is no longer the case.


What happens after network connectivity returns?

|>>>
|>>Are you sure it is samba? Have you tried 2.2.2 on the same box? Of
|>>course smb mounts do not olny involve samba, but the kernel also.
|>>
|>Yes, 2.2.1, 2.2.2, 2.2.3a, on several machines.


Did you get the same or different behaviour?

|>
|>
|>>syslog, dmesg etc?
|>>
|>Syslog shows a kernel failure:
|>
|>Mar  4 23:50:16 nextgen mount.smbfs[2697]: [2002/03/04 23:50:16, 0]
|>client/smbmount.c:send_fs_socket(386)
|>Mar  4 23:50:16 nextgen mount.smbfs[2697]:   mount.smbfs: entering
|>daemon mode for service \\<deleted>\home, pid=2697
|>Mar  4 23:50:35 nextgen kernel: Unable to handle kernel paging request
|>at virtual address f8000000
|>Mar  4 23:50:35 nextgen kernel:  printing eip:
|>Mar  4 23:50:35 nextgen kernel: f8a1bda0
|>Mar  4 23:50:35 nextgen kernel: *pde = 00000000
|>Mar  4 23:50:35 nextgen kernel: Oops: 0000
|>Mar  4 23:50:35 nextgen kernel: CPU:    0
|>Mar  4 23:50:35 nextgen kernel: EIP:    0010:[<f8a1bda0>]    Not tainted
|>Mar  4 23:50:35 nextgen kernel: EFLAGS: 00010293
|>Mar  4 23:50:35 nextgen kernel: eax: 9540420c   ebx: 1526f7b4   ecx:
|>e16423fd   edx: eaa6739c
|>Mar  4 23:50:35 nextgen kernel: esi: f8000000   edi: c9c11e2c   ebp:
|>c9c11ec0   esp: c9c11dec
|>Mar  4 23:50:35 nextgen kernel: ds: 0018   es: 0018   ss: 0018
|>Mar  4 23:50:35 nextgen kernel: Process find (pid: 2699,
|>stackpage=c9c11000)
|>Mar  4 23:50:35 nextgen kernel: Stack: 00000000 00000000 00000000
|>ebc9d8c0 eb5a86e0 764e8045 0009714e d788d506
|>Mar  4 23:50:35 nextgen kernel:        00000000 00000000 eb32a000
|>0000003c 00000000 00000000 00000001 0000003e
|>Mar  4 23:50:35 nextgen kernel:        c9c11e90 00000001 f8a52a20
|>c014b8b0 d9642000 f8a1a331 d2abd0c0 c9c11fa0
|>Mar  4 23:50:35 nextgen kernel: Call Trace: [filldir64+0/352]
|>[<f8a1a331>] [filldir64+0/352] [<f8a1b3ba>] [filldir64+0/352]
|>Mar  4 23:50:35 nextgen kernel: Call Trace: [<c014b8b0>] [<f8a1a331>]
|>[<c014b8b0>] [<f8a1b3ba>] [<c014b8b0>]
|>Mar  4 23:50:35 nextgen kernel:    [<f8a1b752>] [filldir64+0/352]
|>[vfs_readdir+132/224] [filldir64+0/352] [sys_getdents64+79/188]
|>[filldir64+0/352]
|>Mar  4 23:50:35 nextgen kernel:    [<f8a1b752>] [<c014b8b0>]
|>[<c014b334>] [<c014b8b0>] [<c014ba5f>] [<c014b8b0>]
|>Mar  4 23:50:35 nextgen kernel:    [grow_buffers+145/288]
|>[system_call+51/56]
|>Mar  4 23:50:35 nextgen kernel:    [<c0140001>] [<c010725b>]
|>Mar  4 23:50:35 nextgen kernel:
|>Mar  4 23:50:35 nextgen kernel: Code: 0f b6 06 49 46 89 c2 c1 e8 04 c1
|>e2 04 8d 14 1a 01 c2 83 f9
|>

Well, this looks like a kernel smbfs issue ... not a samba issue.


OK, last night I did the following test on each of Mandrake 8.2beta4
/kernel-2.4.18-2mdk/samba-2.2.3a-6mdk, Mandrake
8.1/kernel-2.4.17-5mdk/samba-2.2.1a-15mdk, Mandrake
8.0/kernel-2.4.3-20mdk/samba-2.0.7-25mdk :

$smbmount //screamer/bgmilne screamer
#screamer was running Mandrake 8.2beta3 / samba-2.2.3a-6mdk (I think)
$ ls screamer
#returns a directory listing
#remove ethernet cable
$ls screamer
#does not return
#plug ethernet cable back in
$ ls screamer # on another VC
# both the new and the previously non-returned ls screamer now return a
# directory listing


It is not possible to unmount the mount while the network is down, but
as soon as network connectivity returns, and another process accesses
the share, it works fine (except it cannot be umounted at all after
disconnected operation). I can't reproduce your problem.


|>
|>>Shout if you need a specific release of samba on a sepcific release of
|>>Mandrake (otherwise try rebuilding an rpm from
|>>http://ranger.dnsalias.com/mandrake, for example:
|>>
|>>
|
http://ranger.dnsalias.com/mandrake/samba/RPMS/8.1/2.2.2/samba-2.2.2-7mdk.sr
| c.rpm)
|
| I appreciate the info and offer, and I'll keep them in mind.
|
|
|>Are you cross-mounting samba servers, or smbmounting windows boxes ... ?
|>
|
| Both. In this particular case, it's another samba machine.
|

I would doubt the wisdom of this. If you really need disconnected
operation, intermezzo would be better. If you are running samba on the
other box, why can't users connect directly to it, or even better, setup
  a dfs tree on the machine, so that queries to the "shares" are
redirected to the other machines.

This really isn't what smbfs and samba are for. The samba team
recommends using NFS between samba boxes rather than smbfs cross-mounts.

|
|>You are implying that 2.2.2 was stable? ;-)
|>
|
| Weeeeeeeeeellllllll, at least 2.2.1 was pretty good for me. I'm wishing
| to take advantage of some of the better features introduced in recent
| versions, though.

2.2.1a gave me lots of racing smbd's on our production PDC (about 1 a
week), which were still there in 2.2.2, and I haven't seen in
2.2.3a-1mdk which has been running on our production pdc since 9 Feb.

|
| 2.2.1 doesn't crash at all, even with the same kernel. 2.2.3a definitely
| makes my life miserable, though.

Well, as I say, 2.2.3a is working fine for me, and this looks more like
a kernel issue than anything else. If I can reproduce it, I can try and
track it down, but I can't reproduce this ...

Buchan

- --
|----------------Registered Linux User #182071-----------------|
Buchan Milne                Mechanical Engineer, Network Manager
Cellphone * Work            +27 82 472 2231 * +27 21 8828820x202
Stellenbosch Automotive Engineering         http://www.cae.co.za
GPG Key                       http://ranger.dnsalias.com/gpg.key
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8heihrJK6UGDSBKcRAoMiAKDGkc02n6XswXF0oIjNdWOeCFTOHwCfZXua
403SiEChm5AOXEOWCadldjQ=
=kbv2
-----END PGP SIGNATURE-----


Reply via email to