i have the same exact cifs.ko as you specify in your post. i had a small script put together. it ran something like this.

/sbin/insmod /media/mmc2/cifs.ko
/bin/mount -t cifs //server/share /mount/point -o user=me,password=secret
/bin/mount -t cifs //server/share1 /mount/point1 -o domain=domain,user=me,password=secret

i took the domain out of the first line to see if that was buggering things up, as i really dont have a "domain", although the samba server has a name there. i actually did have the domain= parameter match what the samba server is set to.

this file was owned by root chmod'd 700 and put on the mmc2 (internal) card. of course names were changed to protect the innocent, but it worked once and never again.

now, i see that you have some of the parameters in a different order than i do. is that really an issue?

i went and changed my script to use the parameters in the proper order and i get an error message saying that the mount fails, which is an improvement since i tried it last. before i was getting some other failed message.

now to check to see if cifs uses different ports than smb, as my firewall is pretty well locked down...

edit: cifs uses the some of the same ports (139 and 445) as samba, so that wasnt it. giving up for the day on this one...

One thing I note is that sometimes the mount command is written with '...user=blah,...' and sometimes with '...username=blah,...'. Does it matter?

I just tried using different orders of the parameters in the mount command and also the parameter "user=" and "username=" . Neither makes a difference on my N800 OS4-2007.26.8, it works here.
I think the smbmount requires "username=". Also using smbmount - in case it is available - gives more verbose output than mount. BUT: smbmount mounts smbfs-type shares. This is basically equal to cifs, but a kernel using only the cifs.ko knows only about cifs-type filesystem and smbmount will fail. The filesystems known to the kernel may be listed using

cat /proc/filesystems

I am mounting "local" shares, ie. no firewall in the way, the same network segment.
I would also try mounting using the IP-address not the Windows server name.:

mount .... //192.168.1.3/share /mount-point not
mount ... //server-name/share /mount-point

This removes one tricky point: windows name resolution.
In case you are using a linux samba server, you may check the messages on the server (not the N800 client) while trying to mount: either

tail -f /var/log/messages or
tail -f /var/log/samba/log.smbd.

These filenames are valid on my debian, but these are quite standard. The second source is more verbose.

Good luck.

Thanks for the analysis Huang - appreciate your time and insight.

For the record (I mean if anyone else cares about this other than me I think I've worked out how to solve this but it leaves me a bit puzzled.

Since I unslung my NSLU I can get CLI root access to it. Looking at the permissions of the files within the share I see that they're all;

-rwxrw----

As you'd expect, right? The account I've used on all my LAN clients is in the right group so, in theory, the G permissions should apply. However, if I chmod o+r the files are then accessible on the N800. That's right - problem solved! BUT it leaves me wondering why the NSLU isn't authenticating the account properly when used on the N800? Puzzling to be sure.

Since I don't have any of my LAN open to the big bad world I don't feel too uncomfortable allowing Others read access to the share.

Now, does anyone know how to get chmod to apply permissions recursively through an entire directory tree ?

On a real linux: chmod --help gives the solution: chmod -R.

But your device does not have a fullblown chmod, it uses busybox really.
So --help does not work, but the -R switch works on my N800 -- not sure about NSLU.

yeah, I discovered yesterday that chmod -R o+r * did the trick. Thanks!