Character translation from codepage to iocharset doesn't work, if option
arguments are in wrong order.
Doesn't work: username=remoteuser,uid=localuser,gid=localgroup,
Local system is Linux, remote system is Windows XP. No matter if options are in
fstab or as a arguments for mount or smbmount.
I'm not sure whether this is a matter of options order, or a matter of unknown
options (for smbmount) being passed by mount. I've resolved the issue for me by
renaming smbmount to smbmount2, and putting the following script in place of
opts=`echo $* | sed -e 's/,no[a-z]*//g' -e 's/,user,/,/'`
/usr/bin/smbmount2 $share $mpoint $opts
As you can see, it removes all arguments that mount passes always to smbmount
(no matter what you have in fstab). Here is what smbmount gets and the following
line is the result after filtering:
boils down to
which works. As soon as smbmount encounters an unknown option (such as, for
example, nosuid) it either cheases to parse further options or resets the
charset, I don't understand yet clearly.
It is also possible that this is a different bug, but it's clearly related to
Based on the reponse to bug 2203, it looks like this site is refusing to fix smbclient programs.
A slightly cleaner way to implement your idea on Linux at least is to replace the symbolic link /sbin/mount.smbfs with your script calling /usr/bin/smbmount. Thanks for your workaround.
It's not smbclient. It's smbmount. Please contact the