Windows Problem Solver
Community site – open information exchange
Navigation
Popular content
Active forum topics
Recent comments
|
Some users cannot access a shared driveDear Windows Networking Community, I very much hope someone can help with this one, as we're starting to go a little mad. Our networking set up is WinXP SP2 clients to a SLOX (Suze Linux Open Exchange) domain server. SLOX is functioning as a Samba server and NT domain controller. Everything in respect of this set up works fine. We've just added a Windows XP Professional x64 Edition Version 2003 SP2 machine to the network. This machine will eventually run SQL Server for certain applications, but the first step is share a folder to be accessible by other users (machines) on the network. We have six users with six client WinXP machines on our network, two of these users cannot access the shared folder on the new WinXP x64 machine. When I logout of my own machine and then log back in as the Administrator to the PC and then navigate to the shared folder via the 'network places' icon. My Network Places->Entire Network->Microsoft Windows Network->'Domain'->cal0 I then get the username and password prompt. For four out of the six users, the access works and I can see the shared folder. For two users, I get the following error: ----------- A remote procedure call (RPC) protocol error occurred. We've gone around circles setting the shared permissions, file permissions on the x64 machine. We've tried setting everything to 'everyone' and also just specifying the specific users for access. I've not been able to find any articles on Microsoft.com that relate to this problem, in that the RPC error must somehow be related to the 'problem' users and not my machine set up. Any thoughts or help is much appreciated. Thanks in advance db2007 |
User login
Donations If this web site has helped you, please help us too! Recent blog posts
Windows news ticker
Who's new
Who's online
There are currently 0 users and 9 guests online.
hits since 2007-11-01  |
Proposals
Mon, 2008-03-03 13:47 by admin
Please report back. It would be interesting to know which proposal, if any, solved your problem or at least made it work temporarily.
You could try to re-apply KB828741.
Proposal results
Mon, 2008-03-03 17:12 by dblyth
Hi,
Thanks for the reply. All the machines are fully patched.
The key thing here is that I can get both a positive and negative result from the same client machine, depending on who's user name and password I use.
So all the connectivity, in terms of the hardware, software and protocols, should be in place.
Its very much a 'user centric' problem.
If I remove both a working user and a non-working user from both the share and security permissions of the shared drive on the WinXP x64 machine, then I get two different results when trying to access the share from these:
From the User that used to work I can see the share but get 'Access Denied', as expected.
From the User that did not used to work I still get the RPC error! (very strange), and cannot see the same of the shared drive.
All tests are carried out from the same WinXP SP2 client machine. The same results are found when tried on other machines.
Thanks in advance
db2007
User accounts and passwords
Mon, 2008-03-03 17:22 by admin
Apparently this is a rare and difficult case.
What I would try is to remove a problem user account from both computers and recreate it from scratch, at least to test whether a newly created user works.
Some suspicion falls on the domain controller as well, as the user accounts are there. I would remove a problem user account from the domain controller as well and recreate it.
I would also check the password rules. If they are different on the server and on the domain controller, that could perhaps cause a problem.
user accounts
Mon, 2008-03-03 18:08 by dblyth
We were just starting to ask the same questions, what is the commonality between the working and non-working users?
It will be difficult to delete any user as all users entered into the SLOX domain controller are also part of the Groupware system with all kinds of things like e-mail, projects, jobs, appointments and documents all linked in.
We'll battle on, if we find something I'll post the results here.
Many thanks
db2007
The solution
Thu, 2008-03-06 13:55 by dblyth
The solution was to change the OS from 64-bit to the standard 32-bit WinXP SP2.
WinXP SP2 x64 is basically a cut down version of Windows 2003 Server, full of integration problems when you just want to use it as a client workstation.
Thanks
Thu, 2008-03-06 14:12 by admin
Thanks for reporting back! It's always good to know what worked.
There is the lingering suspicion that the cause was not actually the 64 bit operating system, but something else that was no longer there after installing from scratch. Perhaps something went just a tad wrong when installing the 64 bit XP.
On the other hand, the going recommendation is to always use the 32 bit version if you can, except if you have an overriding reason to use 64 bit. The latter is not often used and not as intensely tested as the more common 32 bit version.
To give one example: there are lots of driver problems. (The 64 bit version needs special 64 bit drivers and cannot use the more common and stable 32 bit ones.) Many manufacturers don't put as much effort into 64 bit drivers, because the market is still small.