1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
|
<chapter id="FAQ-errors">
<title>Common errors</title>
<sect1>
<title>Not listening for calling name</title>
<para>
<programlisting>
Session request failed (131,129) with myname=HOBBES destname=CALVIN
Not listening for calling name
</programlisting>
</para>
<para>
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.
</para>
<para>
Look carefully at your "hosts allow" and "hosts deny" lines in the
global section of smb.conf.
</para>
<para>
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.
</para>
</sect1>
<sect1>
<title>System Error 1240</title>
<para>
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.
</para>
<para>There are two main solutions:
<simplelist>
<member>enable SMB password encryption in Samba. See the encryption part of
the samba HOWTO Collection</member>
<member>disable this new behaviour in NT. See the section about
Windows NT in the chapter "Portability" of the samba HOWTO collection
</member>
</simplelist>
</para>
</sect1>
<sect1>
<title>smbclient ignores -N !</title>
<para>
<quote>When getting the list of shares available on a host using the command
<command>smbclient -N -L</command>
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.
</quote>
</para>
<para>
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.
</para>
<para>
To get the behaviour that you probably want use <command>smbclient -L host -U%</command>
</para>
<para>
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.
</para>
</sect1>
<sect1>
<title>The data on the CD-Drive I've shared seems to be corrupted!</title>
<para>
Some OSes (notably Linux) default to auto detection of file type on
cdroms and do cr/lf translation. This is a very bad idea when use with
Samba. It causes all sorts of stuff ups.
</para>
<para>
To overcome this problem use conv=binary when mounting the cdrom
before exporting it with Samba.
</para>
</sect1>
<sect1>
<title>Why can users access home directories of other users?</title>
<para>
<quote>
We are unable to keep individual users from mapping to any other user's
home directory once they have supplied a valid password! They only need
to enter their own password. I have not found *any* method that I can
use to configure samba to enforce that only a user may map their own
home directory.
</quote>
</para>
<para><quote>
User xyzzy can map his home directory. Once mapped user xyzzy can also map
*anyone* elses home directory!
</quote></para>
<para>
This is not a security flaw, it is by design. Samba allows
users to have *exactly* the same access to the UNIX filesystem
as they would if they were logged onto the UNIX box, except
that it only allows such views onto the file system as are
allowed by the defined shares.
</para>
<para>
This means that if your UNIX home directories are set up
such that one user can happily cd into another users
directory and do an ls, the UNIX security solution is to
change the UNIX file permissions on the users home directories
such that the cd and ls would be denied.
</para>
<para>
Samba tries very hard not to second guess the UNIX administrators
security policies, and trusts the UNIX admin to set
the policies and permissions he or she desires.
</para>
<para>
Samba does allow the setup you require when you have set the
"only user = yes" option on the share, is that you have not set the
valid users list for the share.
</para>
<para>
Note that only user works in conjunction with the users= list,
so to get the behavior you require, add the line :
<programlisting>
users = %S
</programlisting>
this is equivalent to:
<programlisting>
valid users = %S
</programlisting>
to the definition of the [homes] share, as recommended in
the smb.conf man page.
</para>
</sect1>
<sect1>
<title>Until a few minutes after samba has started, clients get the error "Domain Controller Unavailable"</title>
<para>
A domain controller has to announce on the network who it is. This usually takes a while.
</para>
</sect1>
<sect1>
<title>I'm getting "open_oplock_ipc: Failed to get local UDP socket for address 100007f. Error was Cannot assign requested" in the logs</title>
<para>Your loopback device isn't working correctly. Make sure it's running.
</para>
</sect1>
</chapter>
|
