Need Help - Strange XP Home & Simple File Sharing Problem

  • Thread starter Thread starter Dick Sutton
  • Start date Start date
D

Dick Sutton

I have a very curious problem in using 'Simple File Sharing' on Windows XP
Home /SP2 systems. I have a small office LAN of 5 computers, each running
XP Home and connected using SFS. Periodically, I logon to each machine (as
an admin) and run a VBS script to collect/compress selected files and place
this zipped file in a 'networked shared' location (a folder under Shared
Documents on each machine). I then collect these files from each machine by
using another script at another machine and burn them to a CD.



This scripted procedure works for all machines except one. On that machine,
I get an 'access denied' error when I attempt to copy it to the 'mother'
machine.



I have discovered a way to get around the problem. If I go to the affected
users machine and select the folder in question, then turn off sharing of
that folder (via the right-click menu) and then turn sharing back on. Now
the process works correctly.



I use the same script on each machine to collect/compress the selected
files. Therefore, each machine has the same actions performed on it. Only
the one machine has problems (which I can circumvent as described above).



Because XP Home uses SFS, all network access is performed using the guest
account. I don't see why one machine fails. Does anyone have any ideas on
what is wrong?



As a further note, all machines are identical workstations: same make and
model.



Really stumped...



Dick
 
I have a very curious problem in using 'Simple File Sharing' on Windows XP
Home /SP2 systems. I have a small office LAN of 5 computers, each running
XP Home and connected using SFS. Periodically, I logon to each machine (as
an admin) and run a VBS script to collect/compress selected files and place
this zipped file in a 'networked shared' location (a folder under Shared
Documents on each machine). I then collect these files from each machine by
using another script at another machine and burn them to a CD.



This scripted procedure works for all machines except one. On that machine,
I get an 'access denied' error when I attempt to copy it to the 'mother'
machine.



I have discovered a way to get around the problem. If I go to the affected
users machine and select the folder in question, then turn off sharing of
that folder (via the right-click menu) and then turn sharing back on. Now
the process works correctly.



I use the same script on each machine to collect/compress the selected
files. Therefore, each machine has the same actions performed on it. Only
the one machine has problems (which I can circumvent as described above).



Because XP Home uses SFS, all network access is performed using the guest
account. I don't see why one machine fails. Does anyone have any ideas on
what is wrong?



As a further note, all machines are identical workstations: same make and
model.



Really stumped...



Dick
Click to expand...

Dick,

This is interesting. Do you observe this problem each time you try accessing
the share on this one computer?

With XP Home and Simple File Sharing, you can't use the Sharing and Security
wizard to examine and change Access Control Lists. But, there are other
procedures and utilities that might at least identify what the problem is. I've
described a couple possibilities in this article:
<http://nitecruzr.blogspot.com/2005/05/advanced-file-sharing-tweaks-in.html>

Maybe a configuration analysis like Everest will help pinpoint the difference
between the problem computer and the others. It's free, so give it a shot.
<http://www.lavalys.com/products/overview.php?pid=1&lang=en&pageid=1>
 
Chuck,

This happens everytime I use this script. I use the work around that I
described, but its still annoying. When I set up these machines (which are
all new and identical model#s) I used the same procedures to set them up on
each one. That's what's so frustrating.

I'm sure it must be something simple.

I have used CACLS to look at the permissions on this share and on others on
the LAN where the procedure works fine. The 'print outs' are identical.

I will try your suggestions. In the meantime, if you have any further
ideas, let me know...

Dick
 
Chuck,

This happens everytime I use this script. I use the work around that I
described, but its still annoying. When I set up these machines (which are
all new and identical model#s) I used the same procedures to set them up on
each one. That's what's so frustrating.

I'm sure it must be something simple.

I have used CACLS to look at the permissions on this share and on others on
the LAN where the procedure works fine. The 'print outs' are identical.

I will try your suggestions. In the meantime, if you have any further
ideas, let me know...

Dick
Click to expand...

Dick,

Do you run the script against the computers in the same order each time?

Is the "mother" computer running XP Home also? Are you aware of the
simultaneous connection limit?
<http://nitecruzr.blogspot.com/2005/07/server-availability-affected-by.html>

Did you examine CACLS before and after the script was run? Before and after the
problem was observed? Identical results all 4 times?
 
Chuck,
1. I do not run the scripts in the same order each time.

2. The 'mother' computer is another XP Home system, too.

3. Yes, I'm aware of the connection limit. However, I'm only running the
script to copy a file from each computer in turn. That's only 3 computers
accessed serially.

4. Yes, I ran CACLS before and after and comared the results to another
machine (before and after). They were identical.

Dick
 
Chuck,
1. I do not run the scripts in the same order each time.

2. The 'mother' computer is another XP Home system, too.

3. Yes, I'm aware of the connection limit. However, I'm only running the
script to copy a file from each computer in turn. That's only 3 computers
accessed serially.

4. Yes, I ran CACLS before and after and comared the results to another
machine (before and after). They were identical.

Dick
Click to expand...

Dick,

So if you have another computer to run the script on, after the problem
computer, have you tried running it without resetting the server ("mother"
computer)?

So if CACLS shows identical settings in each computer, regardless of the script
status, I think permissioning is pretty much ruled out.

That leaves connectivity. You have 5 computers, one of which is the server (XP
Home). There are cases of extra connections being used, by background
processes. Are you logging in as yourself when running the script, or just
running as the currently logged in user?
 
Chuck,

I think that I may have not communicated correctly. I actually have 4
computers on the LAN. I have another, but its not connected: sorry about
that. Here is the actual scenario that I use. I have a 'mother' computer &
3 other computers lets say called A, B, & C.

First, I run a script on each workstation (A, B & C) that selects a given
set of files and zip's them. That resulting zip file is placed in a shared
folder in the Shared Documents area. That shared folder is set for Read
Only.

After the script has been run on A,B & C, I go to the 'mother' computer and
run another script that simply copies that zip file from each computer (A,
B, &C) onto the 'mother' computer. I then zip those 3 files and burn them
to a CD.

It's when I am copying from A, B &C that I get an Access Denied error on
'mother' saying that I can't access the file on B.

As I've said, if I go back to B and delete the share and re-create it, then
I can run the copy script from 'mother' and all works as expected.

I hope that clarifies. All machines including 'Mother' are XP Home /SP2
(and all updates).

I appreciate your interest in this Chuck. It's driving me crazy.

Dick
 
Chuck,

I think that I may have not communicated correctly. I actually have 4
computers on the LAN. I have another, but its not connected: sorry about
that. Here is the actual scenario that I use. I have a 'mother' computer &
3 other computers lets say called A, B, & C.

First, I run a script on each workstation (A, B & C) that selects a given
set of files and zip's them. That resulting zip file is placed in a shared
folder in the Shared Documents area. That shared folder is set for Read
Only.

After the script has been run on A,B & C, I go to the 'mother' computer and
run another script that simply copies that zip file from each computer (A,
B, &C) onto the 'mother' computer. I then zip those 3 files and burn them
to a CD.

It's when I am copying from A, B &C that I get an Access Denied error on
'mother' saying that I can't access the file on B.

As I've said, if I go back to B and delete the share and re-create it, then
I can run the copy script from 'mother' and all works as expected.

I hope that clarifies. All machines including 'Mother' are XP Home /SP2
(and all updates).

I appreciate your interest in this Chuck. It's driving me crazy.

Dick
Click to expand...

Dick,

OK, you have a server ("mother computer") that's pulling backup data from the 3
clients. That is different. And it's a client computer, acting as a server,
that's the problem.

So you reset the share on Computer B, and it works. Until the next time. So
what's happening to Computer B in the meantime? Is the chronic occurrence of
the problem time related, or event related? Run the scripts once, then
immediately again, without having any normal workday use of any client computer.
See if the scripts are causing a problem in themselves, or if something
happening during the working day is affecting Computer B.

Then compare Everest reports for Computers A, B, and C. Somewhere you'll find a
discrepancy.
 
That is an interesting problem Here's a few thoghts toward narrowing the
problem..

1. Can you access the Shared Docs folder on Computer B outside the script
(e.g. through network places)? Is the Shared Docs folder visible? If so,
can you copy a file from mother to b and back? Can you copy the Zip file?

2. When the problem occurs, open a command prompt on 'mother' and run >net
view \\compbnetname . This should list shares on CompB or may return a
potentially useful error code. You might also run this on CompB using its
own net name. What results?

3. If the share is visible what happens if you try a net use
\\compbnetname\SharedDocs (particularly what error code if any).
 
Chuck,

I have run Everest on the computers and there doesn't appear to be any
discrepancies. There are a lot of pages, so I need to check them again
closely.

Everest mostly reports hardware settings and I am convinced that this is a
software problem. I am inclined to believe it is a permissions issue. When
I manually try to access the shared file from 'mother', I get the following
error:

"Could not open MasterFile.zip. Possible cause: file sharing or file
permissions problem."

I can, however, access other files within the shared folder.

Dick
 
GTS,

Thanks for your interest in this problem. I have answered each of your
questions in order:

1. Yes, I can access computer B manually from 'mother'. However, I cannot
access the given file (I can access other files within the folder). When I
attempt to access the file manually, I get the following:

"Could not open MasterFile.zip. Possible cause: file sharing or file
permissions problem."

Yes, the Shared Docs folder is visible. No I cannot copy a file to computer
B Shared Docs folder. I cannot copy the zip file.

2. When I run the Net View command from 'mother' I get a listing of computer
B's share file and the folder is listed. If I run the same command from
computer B on itself, I get the same listing. The only difference is that
on 'mother', I get <UNC> in the 'Used as' field and blank on computer B.

3. Applying the Net Use command completes successfully on both computers,
however, it makes no difference.

I am convinced that this is somehow a file permissions problem, but I don't
see how...

Dick
 
That's helpful. It's clear that the problem is one of access to this
specific file. That being the case, I think it's either an issue of
permissions (as you note) or of some process holding an open handle to the
file. In either case, it's odd that it happens on the one machine only, but
I would explore these possibilities.

I suggest using Sysinternals Process Explorer to see if some process has the
zip file on Computer B open. If so, then we should look toward how your VB
script operates. BTW, do you run a local copy of that script on each
computer, or do you reference it on 'mother'? (I ask this because of the
fact that deleting and recreating the share on B enables the copy which
should tell us something, though I'm not sure what yet.)
Also, if you reboot B, rather than removing and recreating the share
does that then permit the copy? That would be a further indication of an
open file issue rather than permissions.

If the above doesn't help, permissions bear further study. Your use of
CACLS was a good move and should answer it. If all else fails though, I
would be inclined to boot machine B to safe mode so you can see the security
tab (regrettably required with XP HOME) and see whether it sheds any light
on the issue. You might also be interested in the utility at
http://www.fajo.de/portal/index.php?lang=en&option=content&task=view&id=6&Itemid=47
 
GTS,

I run a local copy of the script on each machine: I do not reference it from
'mother'.

I ran a before and after cacls on the file in question and they were
identical except for the folling lines:

NT AUTHORITY\NETWORK SERVICE:(special access:)

DELETE
SYNCHRONIZE
FILE_READ_DATA

If I remove file sharing on this folder and then re-apply file sharing, this
entry disappears (and my network copy works fine). Furthermore, if I go
into safe-mode and look at the permissions, it says that this item is an
'unknown user'.

Any ideas...

Dick
 
It appears that the file is not being closed. It's a mystery why that
should be different on this particular workstation. If you could post the
script here it would be helpful.
--
 
Back
Top