msdfs on 3.0.25b - hide unreadable on DFS links

Jeremy Allison jra at samba.org
Wed Aug 8 23:22:17 GMT 2007


On Tue, Aug 07, 2007 at 06:55:28PM +0200, Jan Martin wrote:
> (This is the third - and last - one of our recent problems regarding the
> visibility of msdfs contents.)
> 
> 
> In Samba 3.0.24, bug 3319 was fixed ... in a way that one of our most
> important Samba features vanished.
> 
> The situation didn't change by now (SAMBA_3_0_25, this morning)
> 
> We are running a central Samba service as a dispatcher for many file
> services behind it, relying on its ability to hide all entries that the
> user can't see anyway.
> 
> When we installed it some time ago, it was tricky to find out how to do
> it (we had to understand the source), but we succeeded.
> 
> The fix for bug 3319 just excluded all DFS links from hiding. Obviously,
> the involved people didn't see a real use (or possibility) of
> hiding/unhiding for DFS links.
> 
> But for us, it's essential. The hide unreadable feature (even for DFS
> links) was the original reason to set up this service on Samba instead
> of Windows.
> 
> Of course, just reverting the bugfix would result in the old behaviour:
> Without further intervention, DFS links are hidden, so most users can't
> use them. It would be sufficient for our installation (we are running
> the server like that right now as a temporary workaround), but it would
> be a setback for the community.
> 
> So we need another solution.

Currently this looks to me like a feature request (albeit to return to
a mode that we used to support). The problem is the msdfs links are
designed not to point to a valid target, and on some systems there is
no lchmod call to change permissions on symlinks. The ideal solution
would be to use the permissions on the link itself to determine this,
but this would exclude Linux (which doesn't support permission changes
on symlinks). Would this work for you ?

Jeremy.


More information about the samba-technical mailing list