Another Server won't share question

  • Thread starter Thread starter marsha
  • Start date Start date
Pain and despair. nice way to start the day. :-(

Well, the way it is supposed to work is that when a user logs on his
workstation using his userID/password, and then attempts to connect to a
share, the currently logged in userID/password (credentials) are
automatically presented to the share and no prompting should occur. If
prompting does occur, it is asking for a valid userID/password combination
from an account on the SERVER. As long as the exact same userID/password is
being used on both, not prompting would occur.

By any chance... OMG, never thought to ask this... are the workstations at
work configured to log in WITHOUT a password? That would never work.

-Frank
 
By any chance... OMG, never thought to ask this... are the workstations at
work configured to log in WITHOUT a password? That would never work.


Aha!!! I will have to check. They probably do log in without a password.
My computer logs in with just a blank password. Will a blank password
work???

Thanks Frank, you will be my HERO if you figure this out!!!!!!
 
Aha!!! I will have to check. They probably do log in without a password.
My computer logs in with just a blank password. Will a blank password
work???

I've never tried this with a blank password, but I doubt it would work. Just
set the same userID with a password on each box and try it.
Thanks Frank, you will be my HERO if you figure this out!!!!!!\

LOL... good luck.

-Frank
 
Hey Frank and Kurt and others,

I tried it with user and password logging onto network from my computer
but had the same problem.

I just was thinking about the shared folder and went there to try something
that was on my mind. The shared folder contains lots of folders so I tried
to share a sub-folder just to see if I could see it from the user. I can
share
a sub-folder!!!

When I try, I get a Sharing dialog box with the red circle, white x that
says,
"An error occurred while trying to share 1997 Photos [name of sub-folder].
Access is denied. The shared resource was not created at this time.

OK"

So that would keep me from being able to access the folder... right??

Then our of curiousity, I shared the all users folder and could get into it
several layers deep. So If I put the shared data folder in there, maybe it
will work. I will try that right now.
 
I just tried getting anywhere inside the server from my computer and could
drill all
the way down in

\\Server\Documents and Settings\All Users\Start
Menu\Programs\Accessories\Accessibility

But I still can't get insider of the data folder.

Any other thoughts before I kill this windows 2003 server software and
install w2k???
 
Frankster said:
Just out of curiosity, where exactly have you been placing the shared
folder?

I tried it first on the root (C: drive) then in My Documents and then in All
Users when I
saw that I could access All Users. I got the same results everywhere.
 
More...

A shared folder should not be in any "Documents and Settings" folder or sub
folder. It should be off the root by one or more layers. The Documents and
Settings folder is for individual and personal profile stuff. The profile
folders under Documents and Settings are a very unique breed when it comes
to permissions.

Try putting it in C:\SharedFolder\ or C:\Shares\Datafolder\ or something
like that.

-Frank
 
Try putting it in C:\SharedFolder\ or C:\Shares\Datafolder\ or something
like that.

It worked!!!!! I'm so excited! Frank, you are truly my hero. It is a
good
thing you aren't here. lol
 
And Frank, you were also right that I needed a password and not just blank
when logging on.

That is why some computers at work connected and others wouldn't. You are
the man!!!!!!!!!!
 
Try putting it in C:\SharedFolder\ or C:\Shares\Datafolder\ or
It worked!!!!! I'm so excited! Frank, you are truly my hero. It is a
good thing you aren't here. lol

H-O-T D-A-M-N!! Glad you got it working!

And... wish I were there!!!!!!!!! :-) LOL!

-Frank
 
Just to clarify what Frank is saying here.. Your computer does not log on
with no password, your user account does. It is the user accounts that must
match. The computer name has nothing whatsoever to do with this. Blank
passwords should work as long as they're blank on both the client and server
computers.

....kurt
 
Kurt said:
Just to clarify what Frank is saying here.. Your computer does not log on
with no password, your user account does. It is the user accounts that must
match. The computer name has nothing whatsoever to do with this. Blank
passwords should work as long as they're blank on both the client and server
computers.

Right, I may have said it somewhat sloppy, but what I meant is that the user
name
on both the computer and the server had blank passwords and that would not
work.
It was only after I changed the password to 6 digits (the only one I tried -
not sure
how many digits are required) on the user computer and then also on the
server for
that user name, that I could get into the data folder.

That and as posted slightly earlier, I had to move the data folder into a
folder for it to
work. When I had just the data folder (shared with permissions) on the C
drive, it
wouldn't work. I tried it countless times. But after putting the data
folder inside of a
folder, it worked.

That and replacing the blank password with 6 digits made the difference. I
did nothing
but those two things to get it to work. Of course, I don't understand why
that is but that
is what it took for it to work. As you know, I have been working on this
for what seems
forever. I do know that at work where we use a w2k OS on the computer that
serves
the data folder, neither of those conditions make a difference. At least,
I'm certain that
some of the users log on with blank passwords. I'm not truly certain
whether the data folder is
inside another folder or not. I just can't remember in this brain-burnt
state.

But once again, I can't thank you and Frank enough. I have learned a
tremendous amount
even though it has been very painful. Now that I have gotten through the
pain, I will try once
again tomorrow evening to reproduce the situation and double check the
solution. In other
words, I will try to logon with user that has blank password and with
matching user and blank
password on server, see once again if that works or doesn't work. I will
let you know. I will
also move the data folder out of the folder and put it on the C root to
verify that the requirement
for it to be inside of a folder is indeed critical as it appeared to be
tonight.

But tonight is over for me - all except the sleeping (I hope). But I feel
so much better!!!
 
I could duplicate one "fix" but not the other.

Every time I create a user on my computer AND on the server that has
a blank (no password) password, it is unable to connect to the data folder.


However, when I moved the data folder out of the container folder (on
server)
on the C drive, I could still connect to it. I don't understand that
because I
thought last night it was necessary to have it in a container folder. Last
night I
was extremely tired but I was sure that when I moved it into a folder on the
C
drive, it started working. When I started the whole process, I originally
put the
data folder on the C drive but had no luck. Of course, it doesn't make
sense
that it would work inside a folder since it is already a folder with all the
data
inside folders in it. So adding one layer of folders really doesn't make
sense. But last
night I thought it was part of the process towards making the data
accessible.
 
That is interesting. I don't know if I've ever tried that, I just assumed it
should work. I'll give it a try and let you know the result.
 
AHA!

If you go to administrative tools and open local security policy as such:

Local Security Settings
-> Local Policies
-> Security Options
-> Accounts:Limit local account use of blank passwords to console
logon only

You'll find that this policy is enabled by default! I'm sure (reasonably)
that this is not the case in Windows 2000. But I'll bet if you disable the
policy, blank passwords will work for network access.

....kurt
 
Kurt said:
If you go to administrative tools and open local security policy as such:
Local Security Settings
-> Local Policies
-> Security Options
-> Accounts:Limit local account use of blank passwords to console
logon only

You'll find that this policy is enabled by default! I'm sure (reasonably)
that this is not the case in Windows 2000.

I figured it was probably a security setting. I'm glad it is an option
although
as long as we know about it, it isn't really a problem. But it was
different from
w2k and it certainly caused me to stumble in the setup. It created a
situation
where you and Frank were telling me to set up the user/password the same for
server as user. I was doing that (about 25 times) and it wasn't working.
So it
is especially good for you and Frank to be aware when the next newbie
complains
that they can't access a share, that it could be the problem.

I still don't understand the folder in a folder thing that happened last
night. I only have
had a minute since my test this morning (to check this my FAVORITE ng :-)
and so I
haven't done any more tests. I will try resetting the security option to
check it out.

later!
 
I moved it into a folder on the C drive, it started working.

Over time, there are a few places I have learned NOT to put shared folders,
because the *system* treats them differently than *normal* folders.
Basically, avoid all the customary default system folders, make your own.

Here are some to avoid...

C:\
C:\Windows
C:\Windows\System32
C:\Recycled
C:\Recycler
C:\Program Files
C:\Documents and Settings
C:\System Volume Information

Bottom line... when you want to share something, create the folder yourself,
somewhere off the root of the drive. Doesn't really matter how *deep* it is.
First level, second level, etc., is irrelevant.

-Frank
 
Over time, there are a few places I have learned NOT to put shared folders,
because the *system* treats them differently than *normal* folders.
Basically, avoid all the customary default system folders, make your own.

Here are some to avoid...

C:\
C:\Windows
C:\Windows\System32
C:\Recycled
C:\Recycler
C:\Program Files
C:\Documents and Settings
C:\System Volume Information

Bottom line... when you want to share something, create the folder yourself,
somewhere off the root of the drive. Doesn't really matter how *deep* it is.
First level, second level, etc., is irrelevant.

Good info!!!!!!!!!!!
 
Back
Top