Character translation from codepage to iocharset doesn't work, if option arguments are in wrong order. Example: Doesn't work: username=remoteuser,uid=localuser,gid=localgroup, iocharset=iso8859-1,codepage=cp850 Works: codepage=cp850,iocharset=iso8859-1,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 smbmount: ------------ #!/bin/sh share=$1 shift mpoint=$1 shift 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: -o rw,noexec,nosuid,nodev,noauto,user,fmask=666,dmask=777, credentials=/home/zap/samba/cs::ftp,iocharset=cp1251,codepage=cp866 boils down to -o rw,fmask=666,dmask=777,credentials=/home/zap/samba/cs::ftp,iocharset=cp1251, codepage=cp866 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 this one.
Andrew, 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 kernel maintainers.