Samba FAQ
This FAQ is automatically generated from the Samba bug tracking
system. As such it contains answers that we frequestly send to users
who report problems to samba-bugs@samba.org
Please report inaccuracies or out of date information so it can be
fixed
Index
Thank you for reporting your difficulties with samba-1.9.18 series code.
We regret to advise however that all work on the 1.9.18 code tree has been
closed off with the release of samba-1.9.18p10.
All development efforts are now being focussed on stabilizing samba-2.0.0beta
so it can go into feature freeze for release to stable code as soon as possible.
If you could download the most recent alpha release and report back any
difficulties you may have we will do our best to close them out before
the stable release.
We will still fix major bugs and security holes in 1.9.18p10, but
minor bugs will be fixed only in the 2.0 tree.
Unknown parameter encountered: "domain controller"
Ignoring unknown parameter "domain controller"
As of 1.9.18 the "domain controller" parameter has changed. You should
not need it, but in it's place may need "networkstation user logon = yes".
Please check the smb.conf man page BEFORE using this option so you
understand it's significance.
The domain controller code is now integrated into the main Samba
source code.
Please see http://samba.anu.edu.au/cvs.html for information on how to
download the latest version. You may also wish to join the samba-ntdom
mailing list. See http://samba.anu.edu.au/listproc/ for details.
There is also a separate Samba NTDOM FAQ available in the
documentation section of the samba web site at
http://samba.anu.edu.au/samba/
The following is an example of a problem we see from time to time:
"Samba was working fine. We had to change the IP address of the Samba server.
Following the change Samba does not work. We have tried EVERYTHING - it still
does not work!"
What to check:
--------------
1) Follow all instructions in DIAGNOSIS.txt from the samba docs directory.
2) Locate you browse.dat and wins.dat files. They may be found in the following
typical locations:
/usr/local/samba/var/locks
/var/locks/samba
/opt/samba/var/locks
If you can not locate where samba stores these files you can always run:
testparm | grep lock
3) Shut down samba.
4) Delete the browse.dat and wins.dat files
5) Restart samba.
6) Check that any files you deleted have been recreated.
7) Now follow DIAGNOSIS.txt again.
Cause:
------
Samba will place into these files entries for itself with your old IP
address. When you restart Samba it preloads it's name cache with this
information and expects to be able to resolve it's own address to the
same address as it has just read from these files.
Deleting the files means samba takes a little longer to stabilize on
startup but otherwise will now operate correctly.
In Samba 2.0 this problem has been fixed properly by storing signature
information in the relevant files.
Early versions of Linux did not support shared writeable mmap(). I believe
it was introduced in kernel version 2.0.
There are 3 possible fixes:
1) upgrade to a newer version of the Linux kernel
2) don't compile Samba with FAST_SHARE_MODES defined
3) use Samba 1.9.18 which provides FAST_SHARE_MODES via SysV IPC
shared memory. I believe Linux 1.2 suported this.
In Samba 2.0 configure script will auto-detect the OS capabilities
and will enable shared memory only if available.
The logon errors in the NT event viewer are caused by Samba trying to detect
broken NT password servers.
Some NT servers will accept any username/password for session setup requests
and always validate it, returning a positive session setup response
without the guest bit set. Samba checks for this by deliberately sending
an incorrect password when calling the password server in server
level security. If the incorrect password succeeds then Samba logs
an error and refuses to use the password server.
You can remove this check from the code if you want, but as we have
not yet worked out what causes a NT server to show this behaviour
there is a risk that your NT server will start behaving incorrectly
and thus make your Samba server insecure.
In future versions Samba will have a new security option "security = domain"
which will use the same protocols that NT uses for domain authentication.
(currently Samba uses the method that MS documents, rather than that which
Microsoft actually uses). Once that in place this problem should be solved.
> Are there any Macintosh clients for Samba?
Yes. Thursby now have a CIFS Client / Server called DAVE - see
http://www.thursby.com/
They test it against Windows 95, Windows NT and samba for
compatibility issues. At the time of writing, DAVE was at version
1.0.1. The 1.0.0 to 1.0.1 update is available as a free download from
the Thursby web site (the speed of finder copies has been greatly
enhanced, and there are bug-fixes included).
Alternatives - There are two free implementations of AppleTalk for
several kinds of UNIX machnes, and several more commercial ones.
These products allow you to run file services and print services
natively to Macintosh users, with no additional support required on
the Macintosh. The two free omplementations are Netatalk,
http://www.umich.edu/~rsug/netatalk/, and CAP,
http://www.cs.mu.oz.au/appletalk/atalk.html. What Samba offers MS
Windows users, these packages offer to Macs. For more info on these
packages, Samba, and Linux (and other UNIX-based systems) see
http://www.eats.com/linux_mac_win.html
Microsoft changed WinNT in service pack 3 to refuse to connect to servers
that do not support SMB password encryption.
There are two main solutions:
1) enable SMB password encryption in Samba. See ENCRYPTION.txt in the
Samba docs (this is best done with samba verions more recent than 1.9.18)
2) disable this new behaviour in NT. See WinNT.txt in the
Samba docs
Note that Samba-1.9.18 and later support encrypted passwords without
need to recompile and link with the libdes (DES) library. Refer to the
man page for smb.conf and to ENCRYPTION.txt for information about use
of encrypted passwords.
Please refer to the following URL for more information on this subject:
http://support.microsoft.com/support/kb/articles/q166/7/30.asp
If you are trying the NTDOMAIN version of Samba then please join the samba-technical
list and listen there for a while. I also suggest you read the list archives.
See http://samba.anu.edu.au/listproc/ for more info.
Samba support for NT domain control is still very experimental. Only try it
if you are a programmer willing to experiment.
All bug reports regarding this experimental code should be directed ONLY at
the samba-technical or samba-ntdom mailing lists.
In response to concerns over profile handling:
Profile handling will be looked at seriously once we get the domain code to
stabilize. Until then, what we document in Samba and what works can be in
conflict. We stress again the highly experimental nature of all the NTDOMAIN
code.
In response to concerns over compilation problems: Code updates are
currently pouring in to the samba-2.0.0 code tree. Please note that
this means that code cut at any time until we announce feature freeze
may not compile _or_ if it compiles may not run at all.
The password server behaviour changed because we discovered that bugs
in some NT servers allowed anyone to login with no password if they
chose an account name that did not exist on the password server. The
NT password server was saying "yes, it's OK to login" even when the
account didn't exist at all! Adding the NetWkstaUserLogon call fixed
the problem, and follows the "recommended" method that MS have
recently documented for pass through authentication.
The problem now is that some NT servers (in particular NT
workstation?) don't support the NetWkstaUserLogon call. The call also
doesn't work for accounts in trust relationships.
The eventual solution for this will be to replace the password server
code in Samba with NT domain code as that is developed. For now you
have the choice of compiling Samba either with or without the
NetWkstaUserLogon call in the password server code.
In 1.9.18p3 and later you can disable the NetWkstaUserLogon call with
an option in your smb.conf using the "networkstation user login" option.
Session request failed (131,129) with myname=HOBBES destname=CALVIN
Not listening for calling name
If you get this when talking to a Samba box then it means that your
global "hosts allow" or "hosts deny" settings are causing the Samba
server to refuse the connection.
Look carefully at your "hosts allow" and "hosts deny" lines in the
global section of smb.conf.
It can also be a problem with reverse DNS lookups not functioning
correctly, leading to the remote host identity not being able to
be confirmed, but that is less likely.
We are glad you are interested in Samba, but please read the documentation!
English: http://samba.anu.edu.au/samba
German: http://samba.sernet.de
Japanese: http://samba.bento.ad.jp
French: http://www.bde.espci.fr/homepage/Patrick.Mevzek/samba
From the README file:
DOCUMENTATION
-------------
There is quite a bit of documentation included with the package,
including man pages, and lots of .txt files with hints and useful
info. This is also available from the web pages. There is a growing
collection of information under docs/faq; by the next release expect this to
be the default starting point.
FTP SITE
--------
Please use a mirror site! The list of mirrors is in docs/MIRRORS.txt.
The master ftp site is samba.anu.edu.au in the directory pub/samba.
MAILING LIST
------------
There is a mailing list for discussion of Samba. To subscribe send
mail to listproc@samba.anu.edu.au with a body of "subscribe samba Your Name"
Please do NOT send this request to the list alias instead.
To send mail to everyone on the list mail to samba@listproc.anu.edu.au
There is also an announcement mailing list where new versions are
announced. To subscribe send mail to listproc@samba.anu.edu.au with a
body of "subscribe samba-announce Your Name". All announcements also
go to the samba list.
NEWS GROUP
----------
You might also like to look at the usenet news group
comp.protocols.smb as it often contains lots of useful info and is
frequented by lots of Samba users. The newsgroup was initially setup
by people on the Samba mailing list. It is not, however, exclusive to
Samba, it is a forum for discussing the SMB protocol (which Samba
implements). The samba list is gatewayed to this newsgroup.
If you are worried about the security of PWL files then I suggest
you look at http://samba.anu.edu.au/pub/samba/docs/security.html
> Could you please send me Frank Stevensons program for cracking .pwl
> files.
>
> If you have any other programs for cracking windows 95 pwl files, could
> you send them to me or tell me where I can find them.
>
No. These are not part of samba - we will provide only samba components.
For obvious reasons we can not offer any other software like password
cracking tools. These are available from sites like BugTraq.
FAQ Answer about pizza vouchers:
The note about pizza vouchers in the Samba documentation started out
as a bit of a joke. Since then I've been amazed at the number of
people who have managed to send a pizza voucher in one way or another!
I've had many happy evenings eating pizza thanks to these generous
folks!
Some people also write to us wondering how to get a pizza voucher to
Australia. Here are the techniques that have worked for others:
1) a few people have successfully talked their local Pizza Hut
shop into sending vouchers to Australia. Apparently the staff
look at you a bit strangely at first but at least 2 people have
succeeded!
2) Others have rung up a local pizza outlet in Canberra (where I
live) and have offered their credit card numbers over the phone.
They then emailed me telling me which shop to ring up to order
pizza. This has worked with two different shops here in Canberra
- Pizza Hut and Dominos Pizza.
3) I've received several pizza vouchers that are valid in various
places around the world and have started a small collection. Some
day I hope to eat my way through them when I visit some of these
places.
4) I've received several .gif files of pizzas and even some nice
pictures and cardboard pizzas!
Please remember that the "pizza voucher for Samba" thing started
as a joke. It's a lot of fun but you certainly are not required
to send anything. I won't starve without them and maybe I'll put
on a bit less weight :-)
Also remember all the other people who help with Samba. If someone
helps you particularly then maybe just send them a thank you email?
This sort of thing really is appreciated!
Anyway, if you still want to send a pizza my address is:
3 Ballow Crescent
Macgregor A.C.T
2615 Australia
Phone: +61 2 6254 8209
and the nearest pizza outlet is "Kippax Pizza Hut"
Thanks!
We regret to advise that including smbmount and smbumount in the Samba tarball
has been a mistake. These programs are part of the smbfs package and are NOT
maintained by the Samba-Team. We are currently contemplating the removal
of these programs from the samba tarball since they are a constant cause of
complaint and we do NOT have spare capacity to handle additional load.
SMBFS is available only for Linux. In Samba 2.0 we are introducing a
tool called smbsh that offers similar functionality but is portable to
a large number of Unixes.
System error 1240 means that the client is refusing to talk
to a non-encrypting server. Microsoft changed WinNT in service
pack 3 to refuse to connect to servers that do not support
SMB password encryption.
There are two main solutions:
1) enable SMB password encryption in Samba. See ENCRYPTION.txt in the
Samba docs
2) disable this new behaviour in NT. See WinNT.txt in the
Samba docs
The address samba-bugs@samba.anu.edu.au is meant for reporting bugs
or for obtaining help where you suspect that a Samba bug is involved.
It is not meant as a general helpdesk service. It's not that
we don't want to help (we do!) but we get thousands of emails
and have only a few people to deal with them. Trying to help with
each Samba install personally is way beyond our abilities.
Instead I suggest that you try one of the following resources:
1) The Samba web site at http://samba.anu.edu.au/samba/
2) The mailing list samba@samba.anu.edu.au.
Read http://samba.anu.edu.au/listproc/ for more info on that.
3) The newsgroup comp.protocols.smb
4) a newsgroup specific to your OS, such as comp.os.linux.*
If you can afford it you could also contact one of the many companies
that provide commercial Samba support. See http://samba.anu.edu.au/samba/
and follow the links.
It sounds like either your PCs or your server don't have their timezones
set up correctly for daylight savings time or just disagree on the time
zone your are in.
Without knowing what sort of system you are running Samba on it is difficult
to know what to change. If you want to use a "quick fix" then maybe the
"time offset" command in smb.conf will be useful.
> Log message "you appear to have a trapdoor uid system"
This can have several causes. It might be because you are using a uid
or gid of 65535 or -1. This is a VERY bad idea, and is a big security
hole. Check carefully in your /etc/passwd file and make sure that no
user has uid 65535 or -1. Especially check the "nobody" user, as many
broken systems are shipped with nobody setup with a uid of 65535.
It might also mean that your OS has a trapdoor uid/gid system
This means that once a process changes effective uid from root to
another user it can't go back to root. Unfortunately Samba relies on
being able to change effective uid from root to non-root and back
again to implement its security policy. If your OS has a trapdoor uid
system this won't work, and several things in Samba may break. Less
things will break if you use user or server level security instead of
the default share level security, but you may still strike
problems.
The problems don't give rise to any security holes, so don't panic,
but it does mean some of Samba's capabilities will be unavailable.
In particular you will not be able to connect to the Samba server as
two different uids at once. This may happen if you try to print as a
"guest" while accessing a share as a normal user. It may also affect
your ability to list the available shares as this is normally done as
the guest user.
Complain to your OS vendor and ask them to fix their system.
Note: the reason why 65535 is a VERY bad choice of uid and gid is that
it casts to -1 as a uid, and the setreuid() system call ignores (with
no error) uid changes to -1. This means any daemon attempting to run
as uid 65535 will actually run as root. This is not good!
Typical question:
> So here's the problem (and I apologise if this is just a configuration
> issue). On any of our NT Workstation clients (with the reg edit to allow plain
> passwords), once a drive is mapped using userid and password with \\host\anyuser,
> that user can subsequently issue \\host\root and mount the unix box at the root
> directory without any authentication required .. they have access to the whole
> machine.
Samba does NOT second guess the security policy you wish to impose upon
your site. You, as a system administrator for your Unix system, have the
responsibility to determine by means of setting correct user, group and
other permissions who can access what on your Unix system.
If you really want to restrict users so they can not connect to any other users'
home directory then you will need to set the Unix permissions on your users home
directory to drwx------ (Octal 0x700).
> In windows when i set up a share in "user mode" i get the message:
> "You cannot view the list of users at this time. Please try again later."
>
> I know you have lists of users for access and aliasing purposes, but i
> have read nothing to support the idea that these lists control the Domain
> Users List...
Samba does NOT at this time support user mode access control for
Window 9x although we hope to support it in an upcoming release.
> WIN-NT workstations (nt4.0, service pack 3)
> samba with
> security = user
> encrypt passwords = yes
> guest account = guest
>
> start the explorer on a win-nt workstation and select network. I find
> my unix server running samba, but I can not see the list of shares
> unless I am a user, who is known in the smbpasswd of the unix machine.
> The guest account "guest" exists on my unix machine. For testing I even
> made him a regular user with a password.
>
> With my network monitor I can see, that the win-nt workstation uses the
> current login, to connect to IPC$ on the samba server
> (for example "administrator"), not the guest account.
This is exactly how Windows NT works. You MUST have a valid account on the Windows
NT box you are trying to see the resource list on. If your currently logged in
account details do NOT match an account on the NT machine you are trying to access
then you will be presented with a logon box for that machine. When you enter the
name of an account on that machine / domain, together with a valid password then
the resource list is made available. If the account details are not correct then
no resource list is shown.
Samba follows the behaviour of Windows NT exactly.
Samba can be compiled with the GUEST_SESSION_SETUP option at 0,1 or 2.
The default is 0. If this is set to 1 or 2 then Windows NT machines that DO NOT
have an account on the Samba server will see the resource
list. Unfortunately Windows client bugs mean that using this option
will probably cause more problems than it will solve. We do not
suggest that you use it.
FAQ answer about Win95 (with TCP/IP update or OSR2 version) and
Win98 and Samba:
Microsoft changed Win95 upon release of their OSR2 version to refuse to
connect to servers that do not support SMB password encryption. This
change was also released in a TCP/IP update for Win95 and is included in
all versions of Win98 that we've seen so far.
There are two main solutions:
1) enable SMB password encryption in Samba. See ENCRYPTION.txt in the
Samba docs
2) disable this new behaviour in Win95/98. See Win95.txt in the
Samba docs
The Samba docs directory is included with any recent Samba distribution
or available at ftp://samba.anu.edu.au/pub/samba/docs/
NOTE: You must reboot your machine for these registry changes to take effect.
> I've Samba running as a NT-Server, but there is a problem :
>
> When i want to share something on the win95-client, this client wants a
> userlist from the NT-Server (Samba).
> How can I make Samba providing a userlist ?
Sorry. This is not yet supported. Some time after we release samba-2.0.0
we will commence the long task of implementing this functionality. For now
you can should not put your Win95 or Win98 system into User Level Access
mode.
Please refer to the following URL:
http://support.microsoft.com/support/kb/articles/q187/2/28.asp
*** NOTE ***
After making the registry changes referred to in this document
you MUST reboot your Windows 98 PC for the changes to take effect.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Note - the best way to solve this problem is to enable encrypted
passwords on your Samba server. Windows 98 works well with Samba
when Samba is running in encrypted password mode. Samba versions
1.9.18 and later support encrypted passwords providing it is
correctly configured in smb.conf and an smbpasswd file has been
created.
To enable encrypted passwords on Samba, read the file docs/ENCRYPTION.txt
in the Samba distribution.
If you wish to change Windows 98 to send plaintext passwords again,
look on the Win98 CD in the directory '/tools/mtsutil/' you should
find the files: 'ptxt_on.inf' and 'ptxt_off.inf' here is a clip from the
mtsutil.txt file in that directory:
===============================================================
PTXT_ON.INF - SENDS PLAIN-TEXT PASSWORDS TO YOUR NETWORK SERVER
===============================================================
For security reasons, Windows 98 will not allow you to send plain-
text passwords. The password is encrypted by default. However,
Samba servers can be configured to require plain-text passwords,
so you will not be able to connect to Samba servers configured in
this mode unless you change a Registry entry to enable plain-text
passwords.
Caution: Enabling plain-text passwords could compromise security.
To enable plain-text passwords, add the Registry entry for
EnablePlainTextPassword (as a Dword) and set the value to 1 in the
following Registry location:
HKEY_LOCAL_MACHINE\System
\CurrentControlSet\Services\VxD\Vnetsup
--------------------------------------------------
To set the value for EnablePlainTextPassword to 1:
--------------------------------------------------
1. Select PTXT_ON.INF found in the \Tools\MTSutil folder on the
Windows 98 CD.
2. Right-Click PTXT_ON.INF.
-or-
Hold down the SHIFT key and press the function key, F10.
3. Choose INSTALL to add the EnablePlainTextPassword entry and set
its value to 1.
===============================================================
PTXT_OFF.INF - SENDS ENCRYPTED PASSWORDS TO YOUR NETWORK SERVER
===============================================================
To re-enable the sending of encrypted passwords to your network
server, add the Registry entry EnablePlainTextPassword (as a Dword)
and set the value to 0 in the following Registry location:
HKEY_LOCAL_MACHINE\System
\CurrentControlSet\Services\VxD\Vnetsup
--------------------------------------------------
To set the value for EnablePlainTextPassword to 0:
--------------------------------------------------
1. Select PTXT_OFF.INF found in the \Tools\MTSutil folder on the
Windows 98 CD.
2. Right-Click PTXT_OFF.INF.
-or-
Hold down the SHIFT key and press the function key, F10.
3. Choose INSTALL to add the EnablePlainTextPassword entry and set
its value to 0.
This error message means you are using server level security with a password
server that isn't in user level security mode. The password server code
relies on being able to send username/password pairs and getting back a yes/no
response. This isnt possible unless the server is in user level security mode.
The most common reasons for this problem are:
1) you are trying to use a Win95 box as the password server. That won't work.
2) you are using a Samba server as the password server and that server is
configured in share level security.
Samba is year 2000 complient so long as the underlying
operating system that Samba is running upon are year 2000 compliant
(Linux is, as are most modern UNIX systems, along with VMS, MVS and many others
that Samba runs on.)
For a much more detailed discussion and the latest information see
http://samba.anu.edu.au/samba/y2k.html
Many Microsoft clients and applications cannot handle case sensitive
servers. They often change the case of a filename before sending it
over the wire.
In Samba, Just use "short preserve case = yes" and "preserve case = yes".
Never use "case sensitive = yes"
FAQ about comp.protocols.smb:
The newsgroup comp.protocols.smb is quite separate from the
samba mailing list. Someone from outside the Samba team ways
gatewaying messages from the Samba mailing list to
comp.protocols.smb for a while but hopefully this has stopped now.
comp.protocols.smb does contain a lot of discussion about Samba
so it is often a useful resource for Samba users.
For info on accessing usenet newsgroups like comp.protocols.smb
please ask a local internet guru. The Samba Team has no way of
knowing how your local news system is setup so we can't help you.
dont descend is not meant to be a security feature, it's an
administrative convenience. It can be easily bypassed.
It is meant for things like /proc to prevent utilities like file manager
from recursing themselves to death in a filesystem that has links back
into itself.
Please use the underlying unix security of file permissions to give you
real security.
Some people report problems with "cacheing" of data. Generally the bug report
goes like this:
- create a file on a unix box
- view the file on a PC via Samba
- change the file on the unix box
- look at the file again on the PC via Samba and the changes are not visible
The first thing to realise is that this is the expected behaviour! The SMB protocol
uses a thing called "opportunistic locking". This allows the client to "safely"
do client side cacheing of file data. The problem is that this cacheing is only
safe if all programs access the files via SMB. As soon as you access the data
via a non-SMB client then you will get data inconsistencies.
The solution is simple! Disable oplocks in smb.conf for those shares that need
to be accessed simutaneously from unix and windows. See the "oplocks" and
"veto oplock files" options in smb.conf(5)
Samba-1.9.18 series supports oplocks.
Samba-1.9.17 series does NOT.
Some Samba users have reported a problem where the icons for programs stored
on the server are not displayed, with generic "exe" icons being displayed instead.
This problem seems to be caused by the client detecting the connection to the
server as "slow". When this happens the client tries to make things a bit faster
by not reading icon information from the remote .exe files.
The problem happens particularly when running Samba with "security=server". In
server level security Samba delays the negprot and session setup replies while
talking to the password server (this is necessary). To make matters worse
Samba initially sends a deliberately bad password to the password server in
order to detect a known bug in some NT servers where they say "yes" to all
passwords. The NT server replies to this bad password very slowly (probably
in an attempt to stop passwor cracking over the network). All this introduces
a approximately 3 second delay in making the connection which is sufficient
to trigger the Win95 "don't display icons" code.
We don't have a solution to this problem, but we can say that (apart from
cosmetics) it is harmless.
If you had read the following (cut and pasted from the 1.9.18p1 Makefile)
you will have noticed the first sentence specifically says that pre-2.1.70
Linux kernels cannot use the version of smbmount included with Samba. As
it states you should use the smbfs utilities available via anon ftp
from the site below.
# If you are using Linux kernel version 2.1.70 and later, you should
# uncomment the following line to compile the smbmount utilities
# together with Samba. If you are using Linux kernel version 2.0.x
# you must use the smbfs utilities from
# ftp://ftp.gwdg.de/pub/linux/misc/smbfs
[snip]
> Machine OS: Linux: Slackware 3.4
[snip]
> What Happened:
[snip]
> Compiling smbpass.c
> gcc: Internal compiler error: program cc1 got fatal signal 6
> make: *** [smbpass.o] Error 1
There appears to be a problem with the GCC binaries supplied with Slackware
3.4 (and possibly a few other systems). For some reason they fall over
when trying to compile the encrypted passwords code in Samba. There are 2
solutions, the first is a short term fix which doesn't always work, and
as far as I can work out the second should always work:
1. Remove the -O from FLAGS1 in your Makefile.
2. Download a new set of GCC binaries (there is one somewhere under
ftp://sunsite.unc.edu/pub/Linux) or rebuild it from the source.
> If I open a Microsoft Office's file like Word for instance from my workstation,
> and I'm not the owner of that file but I have the right to write on it,
> Microsoft Office will change the file's date to the current date even if I did
> not make any modification to the file. This doesn't appear if I'm the owner of
> the file. The result of this matter is that the date of the files on the network
> doesn't mean nothing because the date change of a file as soon as somebody else
> than the owner open it .
This is the expected behaviour and is a result of POSIX semantics. You
can ask Samba to override this, however.
Please see the "dos filetimes" option in the smb.conf man page.
Running 16 bit programs from Windows NT on a Samba mapped drive
---------------------------------------------------------------
The Windows NT redirector has a bug when running against a
Samba or Windows 95 mapped drive and attempting to run a
16 bit executable.
The problem occurs when the pathname to a 16 bit executable
contains a non 8.3 filename complient directory component,
Windows NT will fail to load the program and complain it
cannot find the path to the program.
It can be verified that this is a bug in Windows NT and
not Samba as the same problem can be reproduced exactly
when attempting to run the same program with the same
pathname from a Windows 95 server (ie. the problem still
exists even with no Samba server involved).
Microsoft have been made aware of this problem, it is
unknown if they regard it as serious enough to provide
a fix for this.
One of the reasons this problem is reported frequently
is that InstallShield setup.exe executables are frequently
written as 16 bit programs, and so hit this problem.
As a workaround, you may create (on a Samba server at
least) a symbolic link with an 8.3 complient name to
the non 8.3 complient directory name, and then the 16
bit program will run. Alternatively, use the 8.3
complient mangled name to specify the path to run
the binary.
This will be fixed when Samba adds the NT-specific
SMB calls in Samba 2.0 as once the NT SMB calls are used
this problem no longer occurs (which is why the
problem doesn't occur when running against a drive
mapped to a Windows NT server).
> When getting the list of shares available on a host using the command
> smbclient -N -L <server>
> the program always prompts for the password if the server is a Samba server.
> It also ignores the "-N" argument when querying some (but not all) of our
> NT servers.
No, it does not ignore -N, it is just that your server rejected the
null password in the connection, so smbclient prompts for a password
to try again.
To get the behaviour that you probably want use
smbclient -L host -U%
this will set both the username and password to null, which is
an anonymous login for SMB. Using -N would only set the password
to null, and this is not accepted as an anonymous login for most
SMB servers.
> mount -ufs \\NTSERVER\MOUNT_DIR /sun_mount_point
smbfs is only available for Linux.
in Samba 2.0 we are introducing a utility called smbsh that will
provide similar functionality but is portable to a wide range of
unixes.
> i have installed samba everything seems to be working fine except the
> smbpasswd executable file i can change a users password as root with
> no problem but if a users tries to change his own password.. it would
> give this error:
>
> smbpasswd: machine 127.0.0.1 rejected the session request.
> Error was : code 131
>
> im not sure what i have to add for it to allow this users to change
> their own password.. it seems to be defaulting to the local ip
> address.. ???
>
> please help .. thanks for your time.
>
Firstly, make sure that you do NOT have "bind interfaces only = yes" in your
smb.conf file.
Secondly, if you have specified "hosts allow = xxx.xxx.xxx.xxx/yy" please add
to it "localhost". ie: hosts allow = 123.45.67.0/24 127.
smbpasswd needs to be able to connect to smbd on the local machine, hence it is
trying to connect to the 127.0.0.1 address.
There was a slight error in early versions of smbtar which prevents
the blocksize parameter from working correctly. This was fixed in
Samba version 1.9.18.
For information on unsubscribing or changing your subscribed address
please see the instructions at http://lists.samba.org/
> Further to my previous post, I have made an interesting discovery. This
> particular slowdown only occurs from clients that are running
> Windows 98.
The Windows98 explorer (and possibly other programs) incorrectly set the
"sync" bit in write requests to network shares. This causes an enormous
slowdown as Samba (quite correctly) does a fsync() on the file after each
write. Combine this with the fact that Windows98 explorer uses very small
write sizes (around 1.5k) and you get really terrible results.
In Samba 1.9.18p10 and later we moified Samba to by default ignore
these incorrect sync requests. This results in an enormous performance
increase when using Windows98 explorer.
You can get the old (slow) behaviour back using the "strict sync" option.
If you get "your server software is being unfriendly" when you try to
connect to a server using smbclient then it means that smbclient established
a TCP connection to the server but got garbage (or nothing) back when it
tried to do a NBT "session request" on the open socket. The "unfriendly"
bit comes from the fact that the client is expecting one of a number of
possible error codes as defined in the spec (see RFC1001/1002) but instead
it got something totally different.
This usually means that you aren't successfully talking to a SMB server at all,
and that the socket is connected to something else. A common cause if Samba
is the server is that smbd faled to startup correctly and exited before it
got to the point of answering the session request. Faulty/missing config files
can do this or if you are launching via inetd then maybe your inetd.conf
or /etc/services is setup incorrectly.
|