Main Topics
Browse All TopicsWin 2ksp4 server, PDC in AD environment with ~ a dozen XPsp1 workstations and a 2ksp4 Adv Server member server.
We recently destroyed and recreated our AD. Everything in the new is working great *except* one darn share that absolutely refuses to act as anything but read-only.
This is a mapped drive common to every workstation, and everyone is supposed to have full control on/in it.
I've set the SHARE permissions to include both the Everyone and Authenticated Users groups to have full control, as well as the NTFS security permissions (which are not inheriting permissions from parent objects and set to the same "Everyone" and "Authenticated Users" to have "Full Control" rights).
Everyone that connects to the folder now has read-only access and I have no clue why. When I check the security/advanced/effectiv
Everything looks correct on the server yet no non-admin can connect. Also, if I designate a user as able to take ownership then view the share as that user, it says I can only view the owner. Is there some kind of delay on network share/NTFS security settings propogating over a mapped drive? This is driving me nuts...have rebooted the workstations many times, tried with and without the "Everyone" group included, disconnecting and remapping the drives, etc...What am I missing?
This Question has been solved and asker verified All Experts Exchange premium technology solutions are available to subscription members.
Experts Exchange has been collecting answers to technology questions since 1996…3 million and counting! If you have a question, chances are we already have your answer.
If you can't find the exact answer you're looking for, ask our exclusive community of 50,000 experts. You’ll get a personalized answer from a trusted professional.
Thousands of free tech tips, tricks, how-to’s and tutorials are available in our peer reviewed articles section. See for yourself how smart our experts are, no login required.
Access the answers to your technology questions today.
30-day free trial. Register in 60 seconds.
Members of the expert community talk about why the experience at Experts Exchange is different than what you will find anywhere else.

Try it out and discover for yourself.
30-day free trial. Register in 60 seconds.
Join the community of experts here and help other tech pros by answering question in your area of expertise. You can earn FREE access to all Experts Exchange's premium features and resources.
>When I check the security/advanced/effectiv
(from my original question)
note: "effective permissions".
Your link shows another links that shows *how* to check effective permissions. I already know how to check them (obviously, since I stated I did check effective permissions in the original question). I can sit at the server and pull up the effective permissions and it will quite clearly show full control for any user just as it should. The problem is that the users do *not* have full control since they cannot rename, create, nor delete files on that share, hence my question here. If I'm at a workstation and check effective permissions for the user I'm logged in as, it will also clearly show that the user supposedly has full control...yet they do not (or perhaps they do but something else is wrong...which is what I'm trying to find out. Tomorrow I will try seeing if an admin on the workstation can manipulate/create files from the workstation since they can on the server itself).
Thanks for trying, but that doesn't answer my question :(.
Any other ideas?
i apologize...
i see you tried blowing them away using a /persistent flag? (I've seen people say to blow them away with persistent yes and persistent no)
Try recreating them on a different drive letter, then assuming that works, try to put the original share back?
Does that share have to be hidden, can you test it non-hidden to elimate that as an issue?
There seems to be some debate about using both Everyone and Authenticated Users in shares and NTFS. Doesn't this boil down to everyone. Also what if the share is being used by a service before authentication.
New Share Permissions
With all of the confusion that old share permissions could cause, Microsoft decided to change the rules for default share permissions with the release of Windows XP Service Pack 1. With every operating system after this service pack release (including Windows Server 2003), the new default permissions for all new shared folders is Everyone having Read only access, as shown in Figure 3.
http://www.windowsecurity.
have you searched through some of the other previous paqs? http://search.experts-exch
here's another one: (turns out to be another deny problem)
http://www.experts-exchang
good luck,
-gsgi
Initially, I only had the everyone group. After researching the problem, I came accross the documentation mentioning that MS changed the default for Everyone to read only, and even though I was seeing Full Control checked, I removed the everuone group and added Authenticated Users. After that didn't work, I re-added Everyone, but left Auth Users intact as well. Yes, it is redundant having both groups, but I had tried it with only one or the other.
I'll try the /persistent flag as soon as I get in the office....I hadn't tried that yet and it sounds promising. I'll also check the other links (getting ready to leave for work now). I spent a few hours yesterday on google, EE, and MS sites searching for a solution. I kept getting the same answers in my searches...mostly share permissions not being set, which of course want my problem.
Well, I'm not sure what the problem was (but have a theory)...but it's fixed now. Here's what I did:
From one of the problematic workstations, I disconnected the network drive and used the net use command w/ persistent:yes and had the same problem. Then, I disconnected the drive again and used persistent:no. Same result. Then I disconnected and tried net use with the /user:username@domane.name
I believe the old shares were persistent, and most likely used the old domain's user credentials that apparently were cached. It doesn't make sense to me why the non-existent domain credentials were still the ones used, but I have noticed a few places in our AD where remnants of the nonexistent users still remain (like full control is only given to a user's SID with a "?" icon...mostly for things like WSUS files and services).
Anyway, thanks for participating gsgi....your /persistent suggestion lead me to the solution which is good enough for me!
Business Accounts
Answer for Membership
by: fixnixPosted on 2005-08-29 at 12:29:38ID: 14778555
Additional info, although I don't believe it's relavant:
I have our shares mapped in logon scripts: here's a copy/paste of 2 shares:
@NET USE Z: \\APLCO\Scan$ /YES
@NET USE S: \\APLCO\INSURE /YES
The Z drive is the problematic one (but used to work under the old AD domain). The S drive works as expected.
Most users also have H drives that are Home (Username$) shares that work correctly so it does not appear to be related to being a hidden "$" share.