Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: NetBIOS weirdness (Read 3537 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

NetBIOS weirdness

I recently got a file server that uses samba.  As far as I can tell, it works perfectly.  I can access it using my computer without a problem.

However, I noticed that I can't get my wife's computer to directly access some of our more restricted folders, but not the unrestricted ones.  To use the appropriate terminology, we have a folder called "secure" which is browseable, but not public.  We also have another folder called "share" that is both browseable and public.  She can access "share" but not "secure".  I've given her an account on the file server and given her account full permission for secure.  Whenever she tries to access "secure" she's prompted to enter her username and password, however it never gets accepted.

FWIW, I've arranged the same setup for me, and I can access these folders without a problem.  The one real difference between our setups is that my windows login name (and password) is the same as the username and password on the file server.  Hers is not.  In fact, I'm not sure what to do since her login name is two words "firstname lastname."

Additionally, she doesn't enter a password to login (something I told her she shouldn't do, but she prefers the convenience of not needing a password).  I'm reluctant to add an additional user to her computer since it may require her to enter a password.  Entering a password to access the secure folders on the fileserver is acceptable though.

What I'm trying to do is simply get her to be able to read and write from the secure folder on the fileserver.  We don't have a Primary Domain Controller, nor is this any formal network beyond several computers.  Even so, I'm not even sure where to begin asking questions, since this really isn't a Samba problem.  Any advice or pointers or even questions will be appreciated.  Thanks.

P.S.  One strange thing I've noticed is that my computer can only see itself and the fileserver via "My Network places".  Her computer can see the whole network, including a media center computer I have networked.

Edit:  Doing a bit more research, I realize the problem is technically one with SMB, not NetBIOS.  Substitute SMB for NetBIOS in the subject line for anyone being pedantic.

NetBIOS weirdness

Reply #1 –
What versions of windows are you each running?  Either one of you configured for Simple File Sharing?

-brendan

NetBIOS weirdness

Reply #2 –
Just to make sure... you ran smbuseradd for her account, right?

NetBIOS weirdness

Reply #3 –
Quote from: bhoar on
What versions of windows are you each running?  Either one of you configured for Simple File Sharing?

We're both running Windows XP Professional.  I know, it's a little strange since we're not running a domain, but it didn't cost us extra either.

I had to look up Simple File Sharing since I'm not familiar with it.  It's interesting.  Her computer is configured for it, while mine is not.  I'm now suspecting that may be the source of our problems.  I'll play around with that setting and see if anything different comes up.  Thanks.


Quote from: rjamorim on
Just to make sure... you ran smbuseradd for her account, right?

Essentially yes.  The file server in question is a Thecus N5200, which runs Linux in the background.  I'm fairly certain that their "add user" is calls smbuseradd.

NetBIOS weirdness

Reply #5 –
Quote from: rjamorim on
Quote from: sthayashi on
The file server in question is a Thecus N5200

You guys are *SO* geekish 

Hey, don't knock it , though if you have any questions about it, you know how to contact me.

Anyways, I figured out a working solution for now.  To use an SMB share in a workgroup, your username HAS to be the same as what's listed on the Samba server.  Additionally, you HAVE to be logged in to access the shares.  For some reason, being logged in as a different user name will not allow access, EVEN THOUGH YOU'RE PROMPTED TO INPUT A USERNAME AND PASSWORD WHEN ATTEMPTING TO ACCESS THE SHARE.  Example: if I were logged in as S T Hayashi on my computer, and the Samba server had a user listed as sthayashi, there is no possible way for me to access the server, even when upon access I'm prompted to try a different username and password.

Additionally, I quickly discovered that changing names in Control Panel -> User Accounts doesn't do squat for actually changing the username, it merely changes the "Full Name" tag associated with the account.  You have to go to to Control Panel -> Administrative Tools -> Computer Management -> Local Users and Groups -> Users, right click and hit rename.  Thanks Microsoft, for making this entirely more difficult than it should have been.

The only "problem" with this solution is that passwords cannot be remembered for logging into file server i.e. every time my wife turns on the computer, she'll have to enter a password in order to acces the file server.  However, I'll interpret this as a feature rather than a problem.

Of course, for educational purposes, if anyone has any suggestions or known work arounds, I'm still happy to hear them.  As much as I like to rant and rave about how annoying this stuff can be, I really do like to learn about how it's supposed to be used properly.

NetBIOS weirdness

Reply #6 –
Quote
Anyways, I figured out a working solution for now.  To use an SMB share in a workgroup, your username HAS to be the same as what's listed on the Samba server.


Er, no that isn't the general rule.  However, I've seen other situations where the solution you gave (changing the SMB login to match the Windows login) fixes the problem, but that's really a workaround for a bad client or samba configuration issue.

Quote
Additionally, you HAVE to be logged in to access the shares.
 

Well, yes, unless you've scripted a system-wide share mount, the cifs client only gives access to the user who supplied the credentials.  Switching to another local windows account (either via fast user switching or remote admin), you no longer are logged in and any mapped drives the other user had are not present.  Seems like the correct behavior on a multi-user system.

Quote
For some reason, being logged in as a different user name will not allow access, EVEN THOUGH YOU'RE PROMPTED TO INPUT A USERNAME AND PASSWORD WHEN ATTEMPTING TO ACCESS THE SHARE.


Again, I think the setup is suffering from a samba (on NAS) or windows (on client) config problem.  It could be as simple as windows forcing itself to use previously cached login credentials, which can be cleared by proper user of the "net use" command's "/d" delete option at the command prompt.  Try "help net" or "net help use", I think.

Other things come to mind:  a non-matching Workgroup name, a firewall configured to treat the local lan as non-trusted, etc.

Quote
The only "problem" with this solution is that passwords cannot be remembered for logging into file server i.e. every time my wife turns on the computer, she'll have to enter a password in order to acces the file server.  However, I'll interpret this as a feature rather than a problem.


She should still be able to cache her login credentials when mapping a drive letter during the log in.  Were you able to turn off simple file sharing?

Quote
Of course, for educational purposes, if anyone has any suggestions or known work arounds, I'm still happy to hear them.  As much as I like to rant and rave about how annoying this stuff can be, I really do like to learn about how it's supposed to be used properly.


I hope the above is taken more as pointers as to places to look more closely than any sort of criticism.

My Infrant unit is set to "share" mode, where the login user is the share name and not my windows account name, so I know what you're running into isn't a windows+samba restriction.

Heck, the XP "Wizard" that allows you to configure your local networking on a machine and create a floppy disk that can be used to reconfigure all other local machines to work the same might even help in this situation.

-brendan
 

NetBIOS weirdness

Reply #7 –
Quote from: bhoar on
Quote
Additionally, you HAVE to be logged in to access the shares.
Well, yes, unless you've scripted a system-wide share mount, the cifs client only gives access to the user who supplied the credentials.  Switching to another local windows account (either via fast user switching or remote admin), you no longer are logged in and any mapped drives the other user had are not present.  Seems like the correct behavior on a multi-user system.

I think you misunderstand.  I'll give you an example.  Let's say my samba server only has the usernames "rjamorim" and "bhoar" listed.  On my local computer, I have accounts for "sthayashi" and "rjamorim".  When I'm logged in as sthayashi and I access the samba server, it brings up a username/password prompt.  However, even if I type in rjamorim and rjamorim's password, I still cannot access the samba server.  I can only access the samba server if I logged into my local machine as rjamorim.

Even more strangely is that this is only applicable to non-public shares.  There was no problem accessing the public shares on the Samba server.

Quote from: bhoar on
Quote
For some reason, being logged in as a different user name will not allow access, EVEN THOUGH YOU'RE PROMPTED TO INPUT A USERNAME AND PASSWORD WHEN ATTEMPTING TO ACCESS THE SHARE.
Again, I think the setup is suffering from a samba (on NAS) or windows (on client) config problem.  It could be as simple as windows forcing itself to use previously cached login credentials, which can be cleared by proper user of the "net use" command's "/d" delete option at the command prompt.  Try "help net" or "net help use", I think.

Other things come to mind:  a non-matching Workgroup name, a firewall configured to treat the local lan as non-trusted, etc.
Quote
The only "problem" with this solution is that passwords cannot be remembered for logging into file server i.e. every time my wife turns on the computer, she'll have to enter a password in order to acces the file server.  However, I'll interpret this as a feature rather than a problem.

She should still be able to cache her login credentials when mapping a drive letter during the log in.  Were you able to turn off simple file sharing?

I did turn off simple file sharing.  It seemed to me that was more for sharing files to others as opposed to accessing other's shared files.  I'll look into using the "net use " commands to force it to cache the credentials.  It may simply not be possible since her local computer login uses no password, while the Samba server requires her to use one.
Quote from: bhoar on
Quote
Of course, for educational purposes, if anyone has any suggestions or known work arounds, I'm still happy to hear them.  As much as I like to rant and rave about how annoying this stuff can be, I really do like to learn about how it's supposed to be used properly.

I hope the above is taken more as pointers as to places to look more closely than any sort of criticism.

My Infrant unit is set to "share" mode, where the login user is the share name and not my windows account name, so I know what you're running into isn't a windows+samba restriction.

Heck, the XP "Wizard" that allows you to configure your local networking on a machine and create a floppy disk that can be used to reconfigure all other local machines to work the same might even help in this situation.

I definitely don't see this as criticism and I do appreciate your feedback.  I definitely learned something new in your previous post.  BTW, what setting is the opposite of "share" mode on your fileserver?  I don't think that's an option on my setup, but I could be wrong.

I've been a little distrustful of the configuration Wizard, since the last time I used it, I got the impression that it was designed for people who didn't know what an IP address was, let alone what a DHCP server is.  Subsequently, I didn't think it did anything for ensuring Windows File Sharing was consistant.