On Tue, 02 Oct 2012 01:24:57 -0400 "Lott, Christopher M" <[email protected]> wrote:
> Thank you so much for explaining what should have been utterly obvious. > It worked perfectly when I did this: > > % sudo -i > # echo 0x30030 > /proc/fs/cifs/SecurityFlags > # mount -t cifs //myoldtiredserver/lott /mnt > > I'm still getting used to using echo for communicating with a kernel > module but that's just gonna take time :) > > On 10/01/2012 09:48 PM, Jeff Layton wrote: > > The sudo in the above command just covers the echo command. The shell > > redirection (and hence the write to SecurityFlags) is done as the > > original user, which is why you're getting EACCES. You probably want > > to do something like this to ensure that the shell redirection is done > > as root as well: > > > > $ sudo sh -c "echo 0x30030 > /proc/fs/cifs/SecurityFlags" > > > No problem, shell redirection is tricky and not always obvious... If someone asked me to invent the most unintuitive, obfuscated interface possible for setting up cifs.ko authentication, I'd be hard-pressed to improve on SecurityFlags. Personally, I'd like to see that go the way of the dodo. We ought to have a sane, fixed heuristic that decides what authentication to use based on the NEGOTIATE_PROTOCOL exchange with the server. Then, we could just allow people to override that by setting a sec= mount option. -- Jeff Layton <[email protected]> -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
