Hi! How can I let recent smbd versions let unix clients access and resolve 'wide' symlinks locally? My goal is that clients may use any kind of symlink (internal and external to a mounted share) like on any other unix-style file system without smbd interfering. My understanding is that since version 3.4.6, smbd effectively denies access of clients to 'wide' symlinks, i.e. out of the share, when unix extensions are on. That is at least the behavior I observe on my unix clients. However, the old wide link behavior is desirable in my environment. Setting the 'wide links' option to yes and/or the 'follow symlinks' to no on the server has no effect, neither globally nor on a per-share basis. Is there any other way to tell smbd to not meddle with symlinks? Stefan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 261 bytes Desc: OpenPGP digital signature URL: <http://lists.samba.org/pipermail/samba/attachments/20100303/8ff429b7/attachment.pgp>
On Wed, Mar 03, 2010 at 03:38:58PM +0100, Stefan G?tz wrote:> Hi! > > How can I let recent smbd versions let unix clients access and resolve 'wide' > symlinks locally? My goal is that clients may use any kind of symlink (internal > and external to a mounted share) like on any other unix-style file system > without smbd interfering. > > My understanding is that since version 3.4.6, smbd effectively denies access of > clients to 'wide' symlinks, i.e. out of the share, when unix extensions are on. > That is at least the behavior I observe on my unix clients. However, the old > wide link behavior is desirable in my environment. > > Setting the 'wide links' option to yes and/or the 'follow symlinks' to no on the > server has no effect, neither globally nor on a per-share basis. Is there any > other way to tell smbd to not meddle with symlinks?Remove the check in lp_widelinks() (param/loadparm.c) and recompile. We got bitten badly enough by this that I don't think this should be a user settable parameter I'm afraid. Jeremy.