A non-text attachment was scrubbed... Name: not available Type: text Size: 2910 bytes Desc: not available Url : http://lists.samba.org/archive/samba/attachments/19990608/1b2f9b97/attachment.bat
Samba is not at fault. I have seen this with NFS.
Client: Win95a with FTP Software's Interdrive95 PCNFS client
Server: Sun E4500, Solaris 2.6 with no smb services of any kind.
When attempting to mount exported filesystems, I have seen Windows look
for DESKTOP.INI in hundreds of places (and cases) before finally giving up
and moving on.
I don't know what this file is or what is is supposed to do, but your
problem is not with Samba.
Sounds to me like your fix is to not mount the root directory of the
fileserver. That seems dangerous even to a lazy-ish admin like me ;)
[Darrin]
--
"I have no special gift. I am only passionately curious." - A.
Einstein
Darrin M. Gorski, Research Computer Systems Network Support
Scientific Research Laboratories, Ford Motor Company
Internet: dgorski@ford.com | Tel/Fax: +1 (313) 248-3753
On Wed, 9 Jun 1999, David A. De Graaf wrote:
> I have long been puzzled at the DNS lookups that occur whenever a
> local client tries to view a share on a local server. My local
> network is connected to the world via a modem connection controlled by
> diald, so whenever my own DNS can't find a name, BAM! The dialing
> begins. This is annoying.
> I had added the entry in smb.conf:
> name resolve order = wins lmhosts
> in a (vain) attempt to suppress DNS lookups by samba, but still they
> happened.
>
> I finally tracked the cause. It's a weird interaction between samba
> and amd, the auto-mount daemon.
> (The samba-2.0.4b server is on Linux Red Hat 6.0; the client is W98.)
>
> Whenever a client tries to view a share, the server goes through quite
> a dance. With 'debug level = 4' I can see in the log.client file
> many attempts to find and open 'DESKTOP.INI". Samba looks in
several
> places for this non-existent file before giving up:
>
> /DESKTOP.INI
> /DESKTOP.INI
> /DESKTOP.INI
> /DESKTOP.INI
> /PROC/DESKTOP.INI
> /PROC/DESKTOP.INI
> /NET/DESKTOP.INI
> /NET/DESKTOP.INI
>
> It is the last two tries that provoke diald, because amd interprets
> this as an attempt to auto-mount machine "DESKTOP.INI" at /net.
> Since it doesn't know of any such machine, it sends out a DNS request
> to resolve this name. It fails, of course, but not until the official
> DNS server gives up. After a LOOOONG delay, the originally requested
> share is opened and displayed to the client.
>
> Curiously, samba looks for /NET/DESKTOP.INI only when the the share is
> the root directory of the server. When a lesser share is viewed the
> /NET prefix isn't used.
>
> I tried to find a workaround, but the amd man page is, shall we say,
> opaque. In /etc/sysconfig/amd I found /net specified as the place to
> hang all the automounted file systems, so I changed it to /n.
> Surprise! Now samba prepends /N to DESKTOP.INI and we retain the
> problem.
>
> In /etc/amd.conf reside the rules by which amd operates. There are
> only two lines:
>
> /defaults fs:=${autodir}/${rhost}/root/${rfs};opts:=nosuid,nodev
> * rhost:=${key};type:=host;rfs:=/
>
> I was unable to comprehend this with the "help" of the man page.
> I guessed the '*' was culpable and replaced this line with one
> each for my small collection of machines, naming them explicitly
> instead of the *.
>
> That did the trick. Each attempt to open /NET/DESKTOP.INI fails
> immediately and the requested share is displayed without delay and
> without calling the Internet.
>
> I suppose only God and Mr. Bill know for sure why DESKTOP.INI is
> needed, and why samba looks in such unlikely places for it.
> I'll pray for an answer, because Mr. Bill surely won't tell.
>
> But maybe some wise mortal out there knows, and will tell us.
> I wish I didn't have to enumerate to amd the machines to allow,
> just because samba looks in funny places for this file.
>
> --
> David A. De Graaf DATIX, Inc. Hilton Head Is., SC
> degraaf@rhsnet.com 843-785-3136, -3156 (fax)
>
This situation can cause problems on Solaris 2.6 and higher also. If / is
shared out by Samba and a client opens /home, all home directories
will be automounted because Explorer looks for desktop.ini in each of
the home directories. In our case that's 5400 mounts. Has anybody
else run into this situation and come up with a way to avoid all the mounts?
Bob Schell
--------------------------------------
David A. De Graaf wrote:
I have long been puzzled at the DNS lookups that occur whenever a
local client tries to view a share on a local server. My local
network is connected to the world via a modem connection controlled by
diald, so whenever my own DNS can't find a name, BAM! The dialing
begins. This is annoying.
I had added the entry in smb.conf:
name resolve order = wins lmhosts
in a (vain) attempt to suppress DNS lookups by samba, but still they
happened.
I finally tracked the cause. It's a weird interaction between samba
and amd, the auto-mount daemon.
(The samba-2.0.4b server is on Linux Red Hat 6.0; the client is W98.)
Whenever a client tries to view a share, the server goes through quite
a dance. With 'debug level = 4' I can see in the log.client file
many attempts to find and open 'DESKTOP.INI". Samba looks in several
places for this non-existent file before giving up:
/DESKTOP.INI
/DESKTOP.INI
/DESKTOP.INI
/DESKTOP.INI
/PROC/DESKTOP.INI
/PROC/DESKTOP.INI
/NET/DESKTOP.INI
/NET/DESKTOP.INI
It is the last two tries that provoke diald, because amd interprets
this as an attempt to auto-mount machine "DESKTOP.INI" at /net.
Since it doesn't know of any such machine, it sends out a DNS request
to resolve this name. It fails, of course, but not until the official
DNS server gives up. After a LOOOONG delay, the originally requested
share is opened and displayed to the client.
Curiously, samba looks for /NET/DESKTOP.INI only when the the share is
the root directory of the server. When a lesser share is viewed the
/NET prefix isn't used.
I tried to find a workaround, but the amd man page is, shall we say,
opaque. In /etc/sysconfig/amd I found /net specified as the place to
hang all the automounted file systems, so I changed it to /n.
Surprise! Now samba prepends /N to DESKTOP.INI and we retain the
problem.
In /etc/amd.conf reside the rules by which amd operates. There are
only two lines:
/defaults fs:=${autodir}/${rhost}/root/${rfs};opts:=nosuid,nodev
* rhost:=${key};type:=host;rfs:=/
I was unable to comprehend this with the "help" of the man page.
I guessed the '*' was culpable and replaced this line with one
each for my small collection of machines, naming them explicitly
instead of the *.
That did the trick. Each attempt to open /NET/DESKTOP.INI fails
immediately and the requested share is displayed without delay and
without calling the Internet.
I suppose only God and Mr. Bill know for sure why DESKTOP.INI is
needed, and why samba looks in such unlikely places for it.
I'll pray for an answer, because Mr. Bill surely won't tell.
But maybe some wise mortal out there knows, and will tell us.
I wish I didn't have to enumerate to amd the machines to allow,
just because samba looks in funny places for this file.
--
David A. De Graaf DATIX, Inc. Hilton Head Is., SC
degraaf@rhsnet.com 843-785-3136, -3156 (fax)
------------------------------
When Samba
>This situation can cause problems on Solaris 2.6 and higher also. If/ is>shared out by Samba and a client opens /home, all home directories >will be automounted because Explorer looks for desktop.ini in each of >the home directories. In our case that's 5400 mounts. Has anybody >else run into this situation and come up with a way to avoid all themounts? You can switch off browsable automount points in Solaris by adding "nobrowse" to the list of options in the mount map. Of course, this removes a useful feature which works efficiently in its own environment. What one would really like is a way of configuring Windows _not_ to search every neighbouring sub-directory for desktop.ini. With any share containing many sub-directories this must impose a considerable burden on the server. Simon
>If you really don't need DESKTOP.INI, why don't you put an empty >file to the root of a standard mount so it finds something and >stops its search?Two reasons. Firstly, you can't place a file at the root of an automount point (it isn't a real directory). Secondly, Windows uses desktop.ini to support web-enabled desktops and there could be different data in each directory. So the search would go on even it found a file, unfortunately. Simon
A non-text attachment was scrubbed... Name: not available Type: text Size: 2041 bytes Desc: not available Url : http://lists.samba.org/archive/samba/attachments/19990611/ea2f069c/attachment.bat
>From: "Darrin M. Gorski" <dgorski@ford.com> > >Are you sure that Samba is the one looking for the same file multiple >times, or is it the client? In my PCNFS example, it was the client who >would request that file, multiple times in the same directory. The server >was just doing it's job and trying to find them. >It is the Windows Explorer Shell that is trying to open DESKTOP.INI. The reasons for this are documented in the programming documentation for the above. It will attempt to open it in many directories, if not all. -John WB8TYW#QSL.NET