James Knott wrote:
The installed version is samba-3.5.7-1.17.1.x86_64. While I can work around this, it would be nice to have it work properly. As I mentioned, it's a server at work. Some of the employees will be accessing it while on the road via WinSCP, with links from their home directories to some common areas. WinSCP has no problem with the links. However, when in the office, they'll be using regular LAN shares instead of WinSCP. This is where it breaks, when Samba won't follow the links. I have also shared the /srv parition, so they can get in that way, but then it's inconsistent with the way they work when outside. They're not all computer geniuses, so this point may trip up some of them.
I agree with you , which is why I complained, when it came out, and and ran with a patch as a "short term measure (*giggle...*ROTFLMAO*)..." (sorry)... too stereotypical for words. As I got bitten again (and people thought I was using 'bleeding edge'?!) ... thus the patch submit... figured it was better to push it upstream to the source (I hoped). The impact of the "security bug" that was supposedly a problem -- is that Users could create links that pointed outside of their "shares" -- just like "local users can create symlinks" out of their directory. They still could not access any files that they didn't have permission to access, BUT, since some people considered that what was 'shared' was only to be governed by share definitions, they invalidate wide links when unix extensions are on (which is the default). Another change: wide-links used to be a Global parameter. Now it is a /share parameter, but unix_extensions is a global and defaults to 'on'. If you try to use wide links and don't explicitly have unix_extensions==false in the global section the wide-links call will silently fail unless you have your log messages turned up high enough and look in the log. *sigh* -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org