Jeff Layton | 4 Jan 14:18 2010
Picon

Re: Problem with soft links on samba share

On Thu, 24 Dec 2009 22:29:40 -0500
Jeff Layton <jlayton <at> samba.org> wrote:

> On Thu, 24 Dec 2009 08:17:55 +0300
> gosha-necr <gosha-necr <at> yandex.ru> wrote:
> 
> > Hi friends!
> > I have a trouble with working linux clients in samba resource.
> > My server: FreeBSD 8.0 i386 + Samba 3.4.3, joined in AD based on Win2003
> > 
> > Windows-client work with share ok, without any problems. But i move stations in organization from win to
linux. As client OS i choose mandriva 2010, users logons in linux throught domain and samba resourse mount
with libpam_mount. 
> > 
> > On server in share i'm make soft links to various folders: 
> > ls -la /mnt/big/smb
> > 
> > 1C-Bases -> ../bases
> > Docs -> ../Documents
> > 
> > And on linux clients that links in mounted with mount.cifs, samba resource shows like links, and with
server paths:
> > ls -la /mnt/share
> > 1C-Bases -> /mnt/big/bases
> > Docs -> /mnt/big/Documents
> > 
> > and it's of course not working. Windows clients see in share that links like folders and work with it
without problems.
> > 
> > mount.cifs --version: 
(Continue reading)

Jeremy Allison | 4 Jan 17:40 2010
Picon

Re: Problem with soft links on samba share

On Mon, Jan 04, 2010 at 08:18:33AM -0500, Jeff Layton wrote:
> 
> To be clear, this is really a server-side issue, so you might want to
> bring this up on the samba or samba-technical mailing lists. It might
> be feasible to add a config option to change how symlinks are handled
> when unix extensions are enabled. 

No, I don't think this will happen. It's taken a long time to
get this completely right server side, it would touch a lot of
code paths to change this. Not saying it's impossible, just that
it's not something that any of the active server developers are
going to do as a priority.

With unix extensions turned on, clients should follow their own
symlinks (as NFS - that was the whole point of the design decision).

Jeremy.
Günter Kukkukk | 5 Jan 05:24 2010

when a mounted remote smb server goes down - cifs vfs tries to re-connect - with strange side-effects

Hi Jeff, Steve, ...

I'm running here on opensuse 11.2 - tried default kernel - and now 2.6.33-rc2-0.1-default from latest cifs git.

When mounting a remote smb server - and then that server goes down (just shutdown, no network cable unplugged),
my client KDE4.x desktop becomes _very_ unresponsive - the (kicker) taskbar is now _unusable_ - no response
at all - which also means that a user can't even use the GUI to shutdown.

As soon i restart the remote smb server, all is fine again.

Used many tools (like those from sysstat) - but at least CPU usage seem to be  _not_ the problem.

Could it be some kernel semaphores....?

When the remote server is down, wireshark only shows some 3 seconds tcp/ip traffic on ports 139 and 445.

From the cifs (debug 7) kernel log:

Jan  5 04:38:01 linux300 kernel: [46253.309431]  fs/cifs/inode.c: Getting info on //linux700/homegk                                     
Jan  5 04:38:01 linux300 kernel: [46253.309438]  fs/cifs/cifssmb.c: In QPathInfo (Unix) the path
//linux700/homegk                      
Jan  5 04:38:04 linux300 kernel: [46256.080085]  fs/cifs/connect.c: Socket created                                                      
Jan  5 04:38:04 linux300 kernel: [46256.080740]  fs/cifs/connect.c: Error -111 connecting to server via
ipv4                            
Jan  5 04:38:04 linux300 kernel: [46256.080770]  fs/cifs/connect.c: reconnect error -111                                                
Jan  5 04:38:07 linux300 kernel: [46259.084106]  fs/cifs/connect.c: Socket created                                                      
Jan  5 04:38:07 linux300 kernel: [46259.084773]  fs/cifs/connect.c: Error -111 connecting to server via
ipv4                            
Jan  5 04:38:07 linux300 kernel: [46259.084804]  fs/cifs/connect.c: reconnect error -111                                                
Jan  5 04:38:10 linux300 kernel: [46262.088085]  fs/cifs/connect.c: Socket created                                                      
(Continue reading)

Jeff Layton | 5 Jan 13:18 2010
Picon

Re: when a mounted remote smb server goes down - cifs vfs tries to re-connect - with strange side-effects

On Tue, 5 Jan 2010 05:24:43 +0100
Günter Kukkukk <linux <at> kukkukk.com> wrote:

> Hi Jeff, Steve, ...
> 
> I'm running here on opensuse 11.2 - tried default kernel - and now 2.6.33-rc2-0.1-default from latest
cifs git.
> 
> When mounting a remote smb server - and then that server goes down (just shutdown, no network cable unplugged),
> my client KDE4.x desktop becomes _very_ unresponsive - the (kicker) taskbar is now _unusable_ - no response
> at all - which also means that a user can't even use the GUI to shutdown.
> 
> As soon i restart the remote smb server, all is fine again.
> 
> Used many tools (like those from sysstat) - but at least CPU usage seem to be  _not_ the problem.
> 
> Could it be some kernel semaphores....?
> 
> When the remote server is down, wireshark only shows some 3 seconds tcp/ip traffic on ports 139 and 445.
> 
> From the cifs (debug 7) kernel log:
> 
> Jan  5 04:38:01 linux300 kernel: [46253.309431]  fs/cifs/inode.c: Getting info on //linux700/homegk                                     
> Jan  5 04:38:01 linux300 kernel: [46253.309438]  fs/cifs/cifssmb.c: In QPathInfo (Unix) the path
//linux700/homegk                      
> Jan  5 04:38:04 linux300 kernel: [46256.080085]  fs/cifs/connect.c: Socket created                                                      
> Jan  5 04:38:04 linux300 kernel: [46256.080740]  fs/cifs/connect.c: Error -111 connecting to server via
ipv4                            
> Jan  5 04:38:04 linux300 kernel: [46256.080770]  fs/cifs/connect.c: reconnect error -111                                                
> Jan  5 04:38:07 linux300 kernel: [46259.084106]  fs/cifs/connect.c: Socket created                                                      
(Continue reading)

Günter Kukkukk | 6 Jan 03:16 2010

Re: when a mounted remote smb server goes down - cifs vfs tries to re-connect - with strange side-effects

Am Dienstag 05 Januar 2010 13:18:04 schrieb Jeff Layton:
> On Tue, 5 Jan 2010 05:24:43 +0100
> 
> Günter Kukkukk <linux <at> kukkukk.com> wrote:
> > Hi Jeff, Steve, ...
> >
> > I'm running here on opensuse 11.2 - tried default kernel - and now
> > 2.6.33-rc2-0.1-default from latest cifs git.
> >
> > When mounting a remote smb server - and then that server goes down (just
> > shutdown, no network cable unplugged), my client KDE4.x desktop becomes
> > _very_ unresponsive - the (kicker) taskbar is now _unusable_ - no
> > response at all - which also means that a user can't even use the GUI to
> > shutdown.
> >
> > As soon i restart the remote smb server, all is fine again.
> >
> > Used many tools (like those from sysstat) - but at least CPU usage seem
> > to be  _not_ the problem.
> >
> > Could it be some kernel semaphores....?
> >
> > When the remote server is down, wireshark only shows some 3 seconds
> > tcp/ip traffic on ports 139 and 445.
> >
> > From the cifs (debug 7) kernel log:
> >
> > Jan  5 04:38:01 linux300 kernel: [46253.309431]  fs/cifs/inode.c: Getting
> > info on //linux700/homegk Jan  5 04:38:01 linux300 kernel: [46253.309438]
> >  fs/cifs/cifssmb.c: In QPathInfo (Unix) the path //linux700/homegk Jan  5
(Continue reading)

Jeff Layton | 6 Jan 13:12 2010
Picon

Re: when a mounted remote smb server goes down - cifs vfs tries to re-connect - with strange side-effects

On Wed, 6 Jan 2010 03:16:25 +0100
Günter Kukkukk <linux <at> kukkukk.com> wrote:

> Am Dienstag 05 Januar 2010 13:18:04 schrieb Jeff Layton:
> > On Tue, 5 Jan 2010 05:24:43 +0100
> > 
> > Günter Kukkukk <linux <at> kukkukk.com> wrote:
> > > Hi Jeff, Steve, ...
> > >
> > > I'm running here on opensuse 11.2 - tried default kernel - and now
> > > 2.6.33-rc2-0.1-default from latest cifs git.
> > >
> > > When mounting a remote smb server - and then that server goes down (just
> > > shutdown, no network cable unplugged), my client KDE4.x desktop becomes
> > > _very_ unresponsive - the (kicker) taskbar is now _unusable_ - no
> > > response at all - which also means that a user can't even use the GUI to
> > > shutdown.
> > >
> > > As soon i restart the remote smb server, all is fine again.
> > >
> > > Used many tools (like those from sysstat) - but at least CPU usage seem
> > > to be  _not_ the problem.
> > >
> > > Could it be some kernel semaphores....?
> > >
> > > When the remote server is down, wireshark only shows some 3 seconds
> > > tcp/ip traffic on ports 139 and 445.
> > >
> > > From the cifs (debug 7) kernel log:
> > >
(Continue reading)

Doug Kelly | 7 Jan 06:56 2010
Picon

Handling Kerberos principals that don't match hostnames

In trying to troubleshoot why Kerberos authentication is not working
with our particular setup, I came across some interesting things.  CIFS
currently assumes the principal is either cifs/hostname or host/hostname
(a feature of cifs.upcall).  Not a problem there, per-se, but this
doesn't seem to be a 100% reliable method for determining the principal,
either.  In our case, two circumstances seem to foul up everything:

1) Load balancing, where the client connects to a virtual IP and gets
handed off to a real server.
2) CNAMEs.

smbclient got around these issues by using some data returned by Windows
2003 servers that revealed the SPN clients should use, it seems.
However, 2008 Server has removed this, and the CIFS kernel module
doesn't even try.  So, I started digging for the way Windows does it to
see if the SPN can be determined in a somewhat reasonable fashion.

I've found that the servers return a bevy of information, including the
NetBIOS domain, NetBIOS hostname, DNS domain, and DNS hostname as a part
of the NTLMSSP response... specifically, the NTLMSSP_CHALLENGE packet.
This reveals the real hostname of the machine that you are connecting
to.

So, getting to the point, is it feasible to use the NTLMSSP
process--just so far as to get the challenge packet back--and parse for
the real information?  Granted, it's not the cleanest option, but I've
been trying to think of any way to determine the hostname to connect to
cleanly, and this is the best I can think of.  If the actual hostname is
determined, the upcall program shouldn't even need to be changed.

(Continue reading)

Jeff Layton | 7 Jan 22:30 2010
Picon

Re: Handling Kerberos principals that don't match hostnames

On Wed, 6 Jan 2010 23:56:01 -0600
Doug Kelly <dougk <at> dougk-ff7.net> wrote:

> In trying to troubleshoot why Kerberos authentication is not working
> with our particular setup, I came across some interesting things.  CIFS
> currently assumes the principal is either cifs/hostname or host/hostname
> (a feature of cifs.upcall).  Not a problem there, per-se, but this
> doesn't seem to be a 100% reliable method for determining the principal,
> either.  In our case, two circumstances seem to foul up everything:
> 
> 1) Load balancing, where the client connects to a virtual IP and gets
> handed off to a real server.
> 2) CNAMEs.
> 
> smbclient got around these issues by using some data returned by Windows
> 2003 servers that revealed the SPN clients should use, it seems.
> However, 2008 Server has removed this, and the CIFS kernel module
> doesn't even try.  So, I started digging for the way Windows does it to
> see if the SPN can be determined in a somewhat reasonable fashion.
> 
> I've found that the servers return a bevy of information, including the
> NetBIOS domain, NetBIOS hostname, DNS domain, and DNS hostname as a part
> of the NTLMSSP response... specifically, the NTLMSSP_CHALLENGE packet.
> This reveals the real hostname of the machine that you are connecting
> to.
> 
> So, getting to the point, is it feasible to use the NTLMSSP
> process--just so far as to get the challenge packet back--and parse for
> the real information?  Granted, it's not the cleanest option, but I've
> been trying to think of any way to determine the hostname to connect to
(Continue reading)

Doug Kelly | 8 Jan 00:11 2010
Picon

Re: Handling Kerberos principals that don't match hostnames

On Thu, Jan 07, 2010 at 04:30:17PM -0500, Jeff Layton wrote:
> The CIFS client doesn't currently do mutual krb5 authentication but
> eventually it would be nice if it did.
> 
> The problem with any scheme that relies on getting the SPN in this way
> is that it leaves you open to DNS spoofing attacks even if you can
> support mutual authentication.

That's true... I actually stumbled upon the debate on the mailing list
about a year ago about using Server 2003's SPN provided with the SPNEGO
setup, and it makes sense.  In fact, even from Windows hosts, it appears
the Kerberos authentication fails, and it falls back to NTLMSSP.

Correct me if I'm wrong, but doesn't the current method of operation
that cifs.upcall rely on this?  I guess the difference in expecting a
server's response to contain the real hostname leaves you open for a
man-in-the-middle attack, though, since another host could potentially
spoof the user to connect to a malicious host.

Anyway, not to bring up that whole debate again, but this would be
something that I'd find beneficial, simply because it'd allow me to
Kerberize the entire process of mounting the users' home directories.
I can't see how it'd weaken the security any more than what already
happens with DFS referrals, either.

Thanks!

Doug Kelly
Günter Kukkukk | 8 Jan 05:01 2010

Re: when a mounted remote smb server goes down - cifs vfs tries to re-connect - with strange side-effects

Am Mittwoch 06 Januar 2010 13:12:23 schrieb Jeff Layton:
> On Wed, 6 Jan 2010 03:16:25 +0100
> 
> Günter Kukkukk <linux <at> kukkukk.com> wrote:
> > Am Dienstag 05 Januar 2010 13:18:04 schrieb Jeff Layton:
> > > On Tue, 5 Jan 2010 05:24:43 +0100
> > >
> > > Günter Kukkukk <linux <at> kukkukk.com> wrote:
> > > > Hi Jeff, Steve, ...
> > > >
> > > > I'm running here on opensuse 11.2 - tried default kernel - and now
> > > > 2.6.33-rc2-0.1-default from latest cifs git.
> > > >
> > > > When mounting a remote smb server - and then that server goes down
> > > > (just shutdown, no network cable unplugged), my client KDE4.x desktop
> > > > becomes _very_ unresponsive - the (kicker) taskbar is now _unusable_
> > > > - no response at all - which also means that a user can't even use
> > > > the GUI to shutdown.
> > > >
> > > > As soon i restart the remote smb server, all is fine again.
> > > >
> > > > Used many tools (like those from sysstat) - but at least CPU usage
> > > > seem to be  _not_ the problem.
> > > >
> > > > Could it be some kernel semaphores....?
> > > >
> > > > When the remote server is down, wireshark only shows some 3 seconds
> > > > tcp/ip traffic on ports 139 and 445.
> > > >
> > > > From the cifs (debug 7) kernel log:
(Continue reading)


Gmane