Friday, February 17, 2012 8:57 PMGreetings all,
I have been trying to read up on this and resolve it for almost 2 days with no satisfactory results and am really hoping someone here can give me some insight.
I have a dozen dfs shares created in a 2 server fully meshed dfsr environment in 2008r2. Replication works great, and admin accounts can peruse as they see fit. Regular users can browse to \\x.com\dfsroot and see all the shares. Opening any of the shares results in permission errors. NTFS permissions are set for Users and Domain Users and have successfully replicated.
On either of the enabled target nodes, currently the share permissions in DFS Managers are [B]all un-checked for "Everyone"[/B] for all target folders. No other users or groups are listed. When trying to modify any of the share permissions from either of the nodes in DFS Manager for any of the folders I get the following error:
"\\x.com\x$: The shared folder cannot be modified. The parameter is incorrect"
(X: is the drive letter the target folder is located on).
Could use some input on this. Thanks all.
Saturday, February 18, 2012 2:47 AM
Let me see if I have understood you correctly..
you have a domain based DFS namespace called dfsroot and it points to shares on diffrent servers. You are having problems with users not being able to access the shares within DFS.
Do the users have the required rights on the shares that is included in the DFS namespace?
Can the users access the shares if you skip the DFS? ie \\server\share-A?
Monday, February 20, 2012 8:16 AMModerator
As Oscar said, please use one folder as an example like \\serverA\shareA, with the path d:\shareA in serverA.
Please list the current permission including both Share and Security permission. Check if users have correct permission. An easy way is, as mentioned above, try to access \\serverA\shareA directly and try to read/modify/create files.
As Administrators could access same folders correctly, it seems like a permission issue related to just users.
TechNet Subscriber Support in forum |If you have any feedback on our support, please contact email@example.com.
Monday, February 20, 2012 4:52 PM
As I indicated above - NTFS permissions are set correctly - tried both with read and FC for Everyone and Domain Users.
The problem is with being able to set the share permissions... in that: I can't. When I try to set them from DFS Manager I get: "\\x.com\x$: The shared folder cannot be modified. The parameter is incorrect"
Monday, February 20, 2012 8:32 PM
If you try to access the administrative share \\x.com\x$ does it work?
What rights are set on that one?
Monday, February 20, 2012 9:09 PM
Sorry - I mis-typed above...
It is \\server1\x$ - \\x.com\dfsroot is the dfs namespace and is browseable by all. The actual shares within there are not.
\\server1\x$ is browsable as admin, browsing to it as a user prompts for credentials. No share permissions are set for the root of X:\. Pertaining NTFS permissions are:
Local users: trav/read, list/read, read attrib, read x attrib, read perms, create/append, create/write
Everyone: trav/read, list/read, read attrib, read x attrib, read perms
The shares are located as such: \\server1\x:\dfsroot\share1 (2, 3, etc) and are replicated to \\server2\x:\dfsroot\<same>
Friday, February 24, 2012 3:06 PMBeuller? Beuller???
Friday, February 24, 2012 3:14 PM
No clue what Beuller means :)
Have you tried to modify the share rights from the server (skip DFS manager), Can the users access the shares directly \\server1\share1?
If it is just the DFS namespace that is really broken, kill it and start over.. okey dump it to a file and start over, so you get all targets back, should take less than 30minutes.
Tuesday, March 06, 2012 4:58 PMYes modifying rights from both replication partners works fine - and users can access the server shares directly on both replication partners. I have tried making a parallel dfs namespace with the same result. As such - killing the namespace and re-creating it is unlikely to resolve the issue. As it is a production environment - the downtime associated with this will not be doable without resolution. Rather than taking the "just redo/reboot it and see if that works" approach - an actual diagnosis and determination of where the issue lies is needed.
Wednesday, March 21, 2012 11:22 PM....