Magic script problem

Joerg Lenneis lenneis at
Fri Oct 31 10:06:07 GMT 1997

Geza Makay:

> At 10:50 PM 10/30/97 +0100, you wrote:
>>> One little bug I found, but it is not very important, since there is a
>>> workaround. If you specify a magic script on one of the shares (it is in
>>> our homes section now), then the magic script does not seem to run, if you
>>> create (copy) it in the root directory of that share, but it works just
>>> fine if you put it into any of the subdirectories of that share. We depend
>>> on magic scripts, because our librarian does not know Unix, but still needs
>>> to update sometimes the library databases on our WWW server, and I do not
>>> want to give her explicit file access to that directory (i.e. a share,
>>> where she could write). So I created a small script that does all the works
>>> for her on the Unix machine, and it is run using the magic script. All this
>>> I experienced with Samba 1.9.17p2.
>> The reason for this behaviour can be found in the function check_magic
>> in server.c which is responsible for finding out if a filename is the
>> name of a magic script and if yes to execute the script. The filename
>> of the script is cleaned from any leading slashes and dots as a
>> name relative to the shared directory. If it matches the magic script
>> parameter it is executed using "/bin/sh" with the current directory
>> set to the share's root. If you do not have "." in your path, it
>> cannot be found, but a file in a subdirectory, like "subdir/magic",
>> can be. 

> I do have a '.' in my path, and Samba (even with large log level) does not
> say that it could not start the script. I think it is not quite
> unresonable, if I assume, that when Samba (or any program) wants to start
> another, and it knows the exact location of the other program, then it
> would start it with the full path of the other program rather than
> depending on path or other settings of the host machine. At least that is
> what I would have done.
> But again, it is not very important, since there is a workaround.

> Geza

[ .. ]

You might have "." in your path, but does the smbd process as well? It
gets its own enviroment at startup which is maybe different from the
one you are using.


Joerg Lenneis

University of Economics and Business Administration
Department for Applied Statistics and Data Processing
Augasse 2-6, 1090 Vienna, Austria

Tel. *43/1/31336 4758
email: lenneis at

More information about the samba mailing list