My Documents - repost

[FPS, Romney]

Hi,

Is each user account supposed to have its own private My Documents folder? I
thought this was the case, but when I created a new user account, it
displayed the same files in My Documents and had the same privileges to
those files as the original user account.

To clarify (I hope) ...
I had an existing user account -- User1/Password1, which everyone in the
office used. I wanted to keep the settings for that account, but make its
files private for one particular person and create a separate account for
everyone else.

I renamed the User1/Password1 account and password to
PrivateAccount/PrivatePassword and then created a new account with the
original username and password (User1/Password1). When I opened the "new"
general purpose account (User1/Password1) and looked in My Documents,
however, I could see (and read/write/delete) the same files as I thought
were now only going to be available to the PrivateAccount/PrivatePassword
account.

Could someone please clarify this for me and/or suggest a better way to have
a private folder / private files for one particular user on a computer
shared by a number of people?

Thank you.
Mark

 

[Malke]

Hi,

Is each user account supposed to have its own private My Documents folder? I
thought this was the case, but when I created a new user account, it
displayed the same files in My Documents and had the same privileges to
those files as the original user account.

To clarify (I hope) ...
I had an existing user account -- User1/Password1, which everyone in the
office used. I wanted to keep the settings for that account, but make its
files private for one particular person and create a separate account for
everyone else.

I renamed the User1/Password1 account and password to
PrivateAccount/PrivatePassword and then created a new account with the
original username and password (User1/Password1). When I opened the "new"
general purpose account (User1/Password1) and looked in My Documents,
however, I could see (and read/write/delete) the same files as I thought
were now only going to be available to the PrivateAccount/PrivatePassword
account.

Could someone please clarify this for me and/or suggest a better way to have
a private folder / private files for one particular user on a computer
shared by a number of people?

You cannot simply rename a user account. This only makes a cosmetic
change and doesn't affect any of the underlying folders. What you should
have done was make an entirely new user account for the Private person.
To get out of what you did:

1. Go to the User Accounts applet and create a new user account with a
unique name - not the original username. Assign a password and you can
then make that user's documents private.

2. Still in the User Accounts applet, delete the extra account you made
if desired and reverse the renaming of the first account.


Malke

 

[FPS, Romney]

Thank you, Malke. That explains why it wasn't working.
I don't know if you can help with another issue --
This particular computer that now has a second user account, has been
functioning as a file-server on our LAN. There is one folder on this
computer that is shared. It was designated as "P"-drive across the network;
i.e., the other computers had their "P"-drive mapped to this particular
folder. The folder was password-protected via the original username/password
of the file-server.

With the new, additional user account on this file-server, however,
"P"-drive is only available across the network while the original
username/password account is logged in on the file-server.

I hope this is clear, and am wondering if you have any suggestions.

Thanks again for your help with the original issue.
Mark

 

[Malke]

Thank you, Malke. That explains why it wasn't working.
I don't know if you can help with another issue --
This particular computer that now has a second user account, has been
functioning as a file-server on our LAN. There is one folder on this
computer that is shared. It was designated as "P"-drive across the network;
i.e., the other computers had their "P"-drive mapped to this particular
folder. The folder was password-protected via the original username/password
of the file-server.

With the new, additional user account on this file-server, however,
"P"-drive is only available across the network while the original
username/password account is logged in on the file-server.

I think you need to rethink your whole setup. I'm not saying this to
hurt your feelings in any way, but right now you're doing "management by
crisis". You also didn't mention 1) what versions of XP are running,
Home or Pro; 2) how many computers are on the network. You need to
follow items 1-2 below and that will solve your "P" drive issue.

Here's a rough scenario of a workable network for a small business
without an IT Dept.

1. Pseudo-server running XP Pro. Acts as a file/backup server. It needs
to have user accounts - with passwords - created for each of the users
on the Local Area Network (LAN) as well as an extra one called "tech" or
the like for emergencies.

1a. You can create whatever shares you want, such as your "P" drive and
because the pseudo-server has Pro, you can set very fine-grained
permissions and restrictions on those shares. You don't make files
private on the workstations. You use permissions and access instead.

How to disable Simple Sharing and set permissions on a shared folder in
Windows XP (Pro only)
http://support.microsoft.com/?kbid=307874

HOW TO: Set, View, Change, or Remove File and Folder Permissions in
Windows XP
http://support.microsoft.com/?kbid=308418

2. Workstations, preferrably running XP Pro also. If they run XP Home,
that is doable just not ideal. Each one of those workstations should
have a user name - with password - created that matches the one on the
pseudo-server. Each one of those workstations should also have an extra
tech account for emergencies.

3. No data should be kept on the workstations. All data should be kept
on the pseudo-server and additionally backed up to a second hard drive
(external or internal) as well as burned to DVD-R regularly and taken
off-site.

4. If you have more than 5 workstations (plus the pseudo-server), it is
time to consider replacing the pseudo-server with a real server
operating system. Windows Small Business Server works well if you want
to stay with Microsoft systems.


Malke

 

[FPS, Romney]

Thanks, Malke. I appreciate the time you took in making your response.

I probably didn't make my earlier post very clear.
The pseudo file-server is WinXP Pro.
All data is stored on the file-server, not the workstations
Permissions for the shared folder on the file-server is not an issue; this
is set according to the users' needs.
The workstations have access to the data in this folder via a
password-protected user account which has been added to User Accounts on the
file-server.
Mapping of "P"-drive on the workstations requires entering this user account
info (username and password) in order to map the workstation's "P"-drive to
the shared folder on the file-server.

Access to this shared folder is the issue now that a second user account has
been added to the file-server and which is intended to be used ON the
file-server by one particular person. That is, Username1/Password1 is the
original user account used on the file-server by staff who use the pseudo
file-server as a workstation, as well as being the account that other
workstations use when logging onto their "P"-drive in order to access the
shared folder.

This one particular person, however, would like to have there own
username/password account (e.g., Username2/Password2) ON the file-server in
order to have their own My Documents folder ON the file-server. But, when
they're sitting at the pseudo file-server and log on using
Username2/Password2, this seems to break the connection for the
workstations, which have their "P"-drive mapped to Username1/Password1.

I don't know if enabling Fast Switching on the file-server would allow
Username1/Password1 to still be accessible -- in the background,
so-to-speak -- to the other workstations on the network, even though someone
on the file-server has temporarily switched to Username2/Password2. It
didn't seem to work when I tried it, but then -- as you pointed out -- I
hadn't really changed the accounts by simply renaming them.

Thanks,
Mark

 

[Malke]

Thanks, Malke. I appreciate the time you took in making your response.

I probably didn't make my earlier post very clear.
The pseudo file-server is WinXP Pro.
All data is stored on the file-server, not the workstations
Permissions for the shared folder on the file-server is not an issue; this
is set according to the users' needs.
The workstations have access to the data in this folder via a
password-protected user account which has been added to User Accounts on the
file-server.
Mapping of "P"-drive on the workstations requires entering this user account
info (username and password) in order to map the workstation's "P"-drive to
the shared folder on the file-server.

Access to this shared folder is the issue now that a second user account has
been added to the file-server and which is intended to be used ON the
file-server by one particular person. That is, Username1/Password1 is the
original user account used on the file-server by staff who use the pseudo
file-server as a workstation, as well as being the account that other
workstations use when logging onto their "P"-drive in order to access the
shared folder.

This one particular person, however, would like to have there own
username/password account (e.g., Username2/Password2) ON the file-server in
order to have their own My Documents folder ON the file-server. But, when
they're sitting at the pseudo file-server and log on using
Username2/Password2, this seems to break the connection for the
workstations, which have their "P"-drive mapped to Username1/Password1.

I'll be honest with you - I'm having hard time visualizing what's going
on with your setup. No one should ever be sitting down at your
pseudo-server to do work. Allowing anyone to actually use a server,
pseudo or real, as a workstation is a recipe for disaster.

As far as your "P" drive goes, I can't see how adding an additional user
account changes things unless you have the target folder's permissions
set up incorrectly. Try resetting the permissions on that folder and its
subcontainers (if any). If only a few people are meant to have access,
then only allow access to those people *plus* Administrator. Don't
forget to include Administrator! Review the links I already gave you
about setting permissions.


Malke

 

[FPS, Romney]

Thanks, Malke. I appreciate the time you took in making your response.

I probably didn't make my earlier post very clear.
The pseudo file-server is WinXP Pro.
All data is stored on the file-server, not the workstations
Permissions for the shared folder on the file-server is not an issue; this
is set according to the users' needs.
The workstations have access to the data in this folder via a
password-protected user account which has been added to User Accounts on the
file-server.
Mapping of "P"-drive on the workstations requires entering this user account
info (username and password) in order to map the workstation's "P"-drive to
the shared folder on the file-server.

Access to this shared folder is the issue now that a second user account has
been added to the file-server and which is intended to be used ON the
file-server by one particular person. That is, Username1/Password1 is the
original user account used on the file-server by staff who use the pseudo
file-server as a workstation, as well as being the account that other
workstations use when logging onto their "P"-drive in order to access the
shared folder.

This one particular person, however, would like to have there own
username/password account (e.g., Username2/Password2) ON the file-server in
order to have their own My Documents folder ON the file-server. But, when
they're sitting at the pseudo file-server and log on using
Username2/Password2, this seems to break the connection for the
workstations, which have their "P"-drive mapped to Username1/Password1.

I don't know if enabling Fast Switching on the file-server would allow
Username1/Password1 to still be accessible -- in the background,
so-to-speak -- to the other workstations on the network, even though someone
on the file-server has temporarily switched to Username2/Password2. It
didn't seem to work when I tried it, but then -- as you pointed out -- I
hadn't really changed the accounts by simply renaming them.

Thanks,
Mark

 

[Malke]

Thanks, Malke. I appreciate the time you took in making your response.

But you're just repeating what you've already said. Yes, I know the
pseudo-server is XP Pro. Yes, apparently you've set permissions on the
shared folder at the pseudo-server. Yes, apparently those permissions
are set incorrectly if you are unable to map to a share on the
workstations. As an aside, is there a reason you are mapping the share
instead of just making a shortcut to it? You might want to try just
making a shortcut to the share instead.

Access to this shared folder is the issue now that a second user account has
been added to the file-server and which is intended to be used ON the
file-server by one particular person. That is, Username1/Password1 is the
original user account used on the file-server by staff who use the pseudo
file-server as a workstation, as well as being the account that other
workstations use when logging onto their "P"-drive in order to access the
shared folder.

Again, the above doesn't make any sense to me either from a
what-is-happening standpoint or from a practical day-to-day work
standpoint. Just repeating the information doesn't help. My response is
that simply adding a user account to a computer should not make any
difference to permissions on a share on that computer. You've got
something set wrong, obviously in the permissions or in the quotas or in
the number of concurrent inbound connections, or... Since I can't see
your computers I can't be sure where the tangle is. You also haven't
mentioned what is *in* the share that people are using. Perhaps it is a
database or a program and there are licensing limits or the like.

And if you want to allow someone to use the pseudo-server for work
that's your decision but from a good IT standpoint, it's a bad decision.
I hope you have a backup strategy in place and being implemented because
allowing anyone to touch a server except for maintenance and backup will
cause Tears Before Bedtime sooner or later.

Try making a different user account for the person who is sitting down
at the pseudo-server and adding that user account to the permissions on
the share. Other than that I have no more ideas since as I already said
I don't know exactly what you are doing and why you would allow someone
to use the pseudo-server as a workstation.

If you still can't figure it out, a better solution will be to have a
local professional come on-site and take a look and set you up properly.
This will not be someone from a BigComputerStore/GeekSquad type of
place. Ask friends and colleagues for recommendations. Someone who can
actually see the computers may be able to pinpoint the source of the
troubles immediately where people just reading about it in a newsgroup
cannot.


Malke

 

[FPS, Romney]

Malke,
Thanks for your further response.
However, there still seems to be some confusion regarding what the problem
is -- probably my fault.

Yes, apparently those permissions are set incorrectly if you are unable to

map to a share on the workstations.

It is not, as you stated that I am unable to map to a share on the
workstations. We have successfully mapped workstations to that share for the
past 5 years -- and at another location for approximately 10 years. The
difference between then and now is that there was only a single
username/password combination used on the file-server -- that is, for
someone who is sitting at the file-server and logging onto that computer.
Now, however, we are attempting to have a second username/password
combination available on the file-server. But, logging on under that second
account seems to (temporarily) invalidate the mapping on the other
workstations. These other workstations had previously mapped their
"P"-drives to that shared folder and at the time of the mapping had to
supply the correct username/password combination in order to complete the
mapping.

Nothing has changed in regards to how the workstations log onto the
network. The accounts they use to log onto the network are unchanged and are
still present in the file-server's User Accounts. Privileges haven't changed
in regards to these accounts, nor do they need to. The only thing that has
changed is that someone sitting at the file-server has logged onto the
file-server with a different username and password than what was originally
used on the workstations in mapping to the share on the file-server.

that simply adding a user account to a computer should not make any

difference to permissions on a share on that computer.

It's not just adding another user account to the file-server's User
Accounts; it's also sitting at the file-server and logging in under a
different username and password than what was used in mapping the
workstations' "P"-drives. Perhaps, as you suggest, this should make no
difference. Perhaps the problem is simply due to my trying to rename the
orginal account on the file-server, instead of creating a brand new account,
etc., as you very helpfully pointed out.

is there a reason you are mapping the share instead of just making a

shortcut to it?

Yes. For database operations, we want access to this shared folder to be
seemless; i.e., no prompting in the middle of an operation. That is why the
workstations have a "P"-drive mapped -- for reading and writing data to the
backend database located on the file-server.

You've got something set wrong, obviously in the permissions

Yes, you are correct. In the permissions for the shared folder, username1
was not specifically listed. This was not a problem during the past 5 years,
as long as whoever physically logged onto the file-server (i.e., sitting at
the file-server) did so using username1/password1. When I clicked properties
for the shared folder and specifically added username1, then the mapped link
continued to function even though someone physically logged off of the
file-server as username1 and logged on under username2 -- the other
workstations did not lose their link to the shared folder. Thanks, Malke,
for pushing me to figure this out!

Concerning My Documents: what user groups and/or permissions need to be set
for two user accounts, both with Adminstrator rights, to not be able to see
each other's My Documents files? I created a brand new user account, but
could still read/write/delete the files from the original user's account.
Should only CREATOR OWNER having any privileges for My Documents?

Thanks for your patience, Malke
Mark