We have discovered that if the same machine is acting as client and server, and there is a symlink pointing to *itself* through the SMB mount, that stat() on the link brings the machine to its knees.  Multiple smbd processes fork, the stat() takes either a long time to return or never returns, the system runs out of file descriptors, that kind of stuff.  We have reproduced this with the latest version of Samba and are quite prepared to post the precise details to reproduce it and what we saw, but I think those will be unnecessary once you understand the issue.

Let me give an example.  Suppose the directory /local/foo is exported as share 'foo'.  Now suppose that the client - running on the same machine, remember - mounts that with

    mount -t cifs //localhost/foo /mnt/foo

And now I do:

    cd /local/foo
    ln -s /mnt/foo/bar bar

If I now do anything that stat()s bar, like ls -l /mnt/foo, we're off into NeverNeverLand.

I *know* that sounds like a stupid thing to do in the first place.  Bear with me.

It seems clear to me what's happening - the server gets the request to stat the file, which is linked to an SMB mount, so the stat follows the SMB mount again, and so on.  It's not a recursive symlink that's detectable to the server the same way that it would be if it were linked to /local/foo/bar.  But perhaps it could be detected in the client - am I stat()ing something that's a link to itself on a share that's mounted from localhost - so I want to ask whether the developers want to take it on anyway.

So why are we doing something so asinine?  (1) Why do we have a SMB client running on the same machine as its server?  We have excellent reasons irrelevant here relating to managing authorizations and ownerships for a shared web hosting environment accessed by multiple sharing protocols.  Our architecture would be more complicated if we didn't do that.

(2) Why are we linking a file to itself?  It was one of our users on the shared space that did it - *by accident*.  Three times, no less.  Some fluke move of files to the wrong place.  But it took down the system for everyone.  (Yes, finding the cause was as hard as you might imagine, and then some.)  The users told us, not unreasonably, that no one user should be able to deny everyone else service.  We agree.  Here we are.  Trying to tell management at this point that this was a fluke that can't reasonably be expected to recur, or to tell all our users to make sure that they don't do this by accident - not going to happen.

Absent some change to Samba, our best bet is likely to run iNotify to look for symlinks being created and axe any recursive ones.  But since we couldn't find any indication that anyone has run into this problem before, we wanted to give the Samba developers an opportunity to respond.  Is this something we might see addressed in either the near future or at all?  Thanks.