On Mon, Jan 22, 2007 at 10:50:47AM +1100, Grant Coady wrote: > On Mon, 22 Jan 2007 00:03:21 +0100, Willy Tarreau <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED]:/home/other$ uname -r > 2.4.34b > [EMAIL PROTECTED]:/home/other$ mkdir test > [EMAIL PROTECTED]:/home/other$ ln -s test testlink > ln: creating symbolic link `testlink' to `test': Operation not permitted > [EMAIL PROTECTED]:/home/other$ echo "this is also a test" > test/file > [EMAIL PROTECTED]:/home/other$ ln -s test/file test2 > ln: creating symbolic link `test2' to `test/file': Operation not permitted > > trying to create symlinks. > > No problems creating symlinks with 2.4.33.3.
Yes, I've found that this varies depending upon the options passed. If uid=0, I can create symlinks, otherwise I always get permission denied. This behavior appears to be consistent with 2.6. I also need to do some testing with the proposed patch to smbmount that will let you omit options (current versions will always pass an option to the kernel, even if you the user did not provide one). If you do not pass options, the behavior should fallback to server-provided values. Note that this bug has been my only interaction with smbfs, so I'm certainly no expert on how it *should* behave. My plan is to take all of the use cases we're coming up with and try to maintain the "historic" 2.4 behavior as much as possible, but still not silently dropping user-provided mount options. When the behavior needs to change to honor them, I'll try to match what current 2.6 does. Make sense? -- dann frazier - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
