none
DFS文件服务器的奇怪问题 RRS feed

  • 问题

  • win2008R2域环境,DFS服务器,最近在DFS管理器里,修改了几个共享文件夹的权限,修改完成后,发现所有用户都无法打开这个修改过权限的共享文件夹了,但等了很多小时以后,这个文件夹又恢复了,可以正常访问,不知道这是怎么回事,请高人给帮帮忙,郁闷中~
    2012年7月18日 8:39

答案

  • 嗯,基本上走对路线了。

    你再回头看看你首帖的问题描述,只字未提“改动安全组的成员”,害人啊。。。

    而且,我相信这个问题不但仅存在于DFS NameSpace下,普通Folder Sharing UNC也是一样的吧?

    也许,这篇文档就可以最终解释并解决你遇到的问题了

    Configure Universal Group Membership Caching in Active Directory

    http://technet.microsoft.com/en-us/magazine/ff797984.aspx

    • 已编辑 Finy 2012年7月24日 8:03
    • 已标记为答案 sunkaiwin 2012年7月24日 8:39
    2012年7月24日 7:56

全部回复

  • 能重现吗?能重现就讨论讨论排错步骤;不能重现的历史问题,即使猜对了,也没法验证啊

    2012年7月18日 9:12
  • DFS复制不会立即开始。拓扑和 DFS 复制的设置必须复制到所有域控制器上,并且复制组中的每个成员必须轮询最接近的域控制器,以获取这些设置。所需的时间取决于 Active Directory 复制延迟以及每个成员的长轮询间隔(60 分钟)。


    在IT的路上,You'll never walk alone

    2012年7月18日 9:13
  • 可以前不是这样啊,有什么好的解决办法呢? 难道设置好了,用户要等很多小时才能用?不是吧。

    2012年7月18日 11:30
  • 可以前不是这样啊,有什么好的解决办法呢? 难道设置好了,用户要等很多小时才能用?不是吧。


    把环境、重现问题的步骤、问题的具体表现、你的疑点,都贴出来吧。
    2012年7月19日 3:15
  • win2008R2域环境,两台DC用作两个域命名空间服务器,其中一台安装了DFS,最近在DFS管理器里,修改了几个文件夹的共享权限,修改完成后,发现所有用户都无法打开这个修改过权限的共享文件夹了,但等了很多小时以后,这个文件夹又恢复了,可以正常访问。现象就是这些。
    2012年7月19日 4:00
  • 检查下服务器上系统日志是否正常

    在IT的路上,You'll never walk alone

    2012年7月19日 4:03
  • win2008R2域环境,两台DC用作两个域命名空间服务器,其中一台安装了DFS,最近在DFS管理器里,修改了几个文件夹的共享权限,修改完成后,发现所有用户都无法打开这个修改过权限的共享文件夹了,但等了很多小时以后,这个文件夹又恢复了,可以正常访问。现象就是这些。

    好,再扩展一下你的“所有用户都无法打开这个修改过权限的共享文件夹”的具体表现是什么?
    2012年7月19日 4:18
  • 服务器系统日志看了,找到一些警告:

    1.在没有配置的 DNS 服务器响应之后,名称 _ldap._tcp.dc._msdcs.xxx.com 的名称解析超时。

    2.Remote Insight Agent: The Remote Insight Board/Integrated Lights-Out has detected a controller interface error.
    [SNMP TRAP: 9006 in CPQSM2.MIB]

    3.从计算机 'xxx' 设置会话失败,因为安全数据库 没有包含指定计算机引用的信任帐户 'B-xxx$'。 

    4.从计算机 xxx 设置的会话未能进行身份验证。 发生下列错误:
    拒绝访问。

    现象是,用户尝试打开该共享文件夹的时候,打不开,提示拒绝访问,但实际上用户是有权限访问的。

    过N个小时以后,通常是第二天早晨,就OK了。

    2012年7月19日 6:29
  • "现象是,用户尝试打开该共享文件夹的时候,打不开,提示拒绝访问"

    此时如果注销这个用户并重登录,是否可以访问?

    如果重启这台客户端机器,再登录,是否可以访问?

    如果以上都失败,能否用procmon抓一下整个访问过程。

    2012年7月19日 6:35
  • 此时如果注销这个用户并重登录,不能访问

    如果重启这台客户端机器,再登录,依然不能访问

    procmon抓一下,我去试试看

    在该服务器应用程序日志里看到有许多这样的警告日志:

    日志名称:          Application
    来源:            Microsoft-Windows-CertificateServicesClient-AutoEnrollment
    日期:            2012/7/18 16:41:51
    事件 ID:         64
    任务类别:          无
    级别:            警告
    关键字:           经典
    用户:            暂缺
    计算机:           xxxx.xxx.xxx
    描述:
    具有指纹 d6 ab 8f a8 5c c0 e7 fd 9a bb ed 38 49 8e c5 83 6d 30 ca 0e 的 本地系统 的证书将到期或已到期。
    事件 Xml:
    <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
      <System>
        <Provider Name="Microsoft-Windows-CertificateServicesClient-AutoEnrollment" Guid="{F0DB7EF8-B6F3-4005-9937-FEB77B9E1B43}" EventSourceName="AutoEnrollment" />
        <EventID Qualifiers="32768">64</EventID>
        <Version>0</Version>
        <Level>3</Level>
        <Task>0</Task>
        <Opcode>0</Opcode>
        <Keywords>0x80000000000000</Keywords>
        <TimeCreated SystemTime="2012-07-18T08:41:51.000000000Z" />
        <EventRecordID>44341</EventRecordID>
        <Correlation />
        <Execution ProcessID="0" ThreadID="0" />
        <Channel>Application</Channel>
        <Computer>SHSPDC2.spangchem.com</Computer>
        <Security />
      </System>
      <EventData>
        <Data Name="Context">本地系统</Data>
        <Data Name="ObjId">d6 ab 8f a8 5c c0 e7 fd 9a bb ed 38 49 8e c5 83 6d 30 ca 0e</Data>
      </EventData>
    </Event>

    2012年7月19日 8:20
  • 证书警告是另一回事,你mmc加载计算机证书,进去搜一下指纹为d6 ab 8f a8 5c c0 e7 fd 9a bb ed 38 49 8e c5 83 6d 30 ca 0e的证书,看看他的有效期就知道了。。。

    这个,和DFS问题99%无关

    2012年7月19日 9:12
  • 其实感觉就是文件服务器在接受用户访问的时候,身份验证上的问题,我每次改动过共享文件夹的共享权限后,就要很久以后才能生效,而以前不是这样的,是立即生效的,我就搞不明白,为什么改动DFS共享文件的权限后,要那么久才能生效,究竟问题出在哪里?
    2012年7月19日 11:36
  • 其实感觉就是文件服务器在接受用户访问的时候,身份验证上的问题,我每次改动过共享文件夹的共享权限后,就要很久以后才能生效,而以前不是这样的,是立即生效的,我就搞不明白,为什么改动DFS共享文件的权限后,要那么久才能生效,究竟问题出在哪里?

    请问你改的是哪里的权限?DFS Folder/DFS Target Folder/Folder in DFS Target Foler?

    改的是sharing permission还是NTFS?

    如果所做改动是对权限的放大,最终用户还会被Deny吗?

    2012年7月20日 1:51
  • 对我改的就是DFS管理器里面目标文件夹的共享权限 是Sharing permission 不是NTFS

    经过测试发现,如果改动的是域用户的权限,是立即生效,如果更改的是组(全局,安全组)权限是要很久才能生效,通常要到第二天早晨。

    2012年7月20日 8:04
  • 如果更改的是组(全局,安全组)权限是要很久才能生效

    这句话很关键啊。。。

    你是不是把Infrastructure Master和GC放在一台机器上了?

    如果所做改动是对权限的放大(例如只是往ACL里加Allow条目),最终用户还会被Deny吗?

    • 已编辑 Finy 2012年7月20日 8:51
    2012年7月20日 8:37
  • 没错,我的架构主机的角色在第一台DC上,DFS所在的第二台DC上

    第二个试验还没做,之前我实际操作过的是,改动权限,比如删除一些组的访问权限,加上一些新组的访问权限。

    2012年7月20日 9:21
  • 我实际操作过的是,改动权限,比如删除一些组的访问权限,加上一些新组的访问权限。

    这个操作做完后的现象是不是这样:在短时间内,新加组的用户无法访问,但被删除的却依然可以访问?

    突然还想补充一句:假如你同样更改一个非DFS下的(普通的UNC共享)文件夹,会有此问题吗?(因为我感觉你的问题标题可能有点misleading。。。)
    • 已编辑 Finy 2012年7月20日 10:03
    2012年7月20日 9:41
  • 被删除的用户能不能访问还真没试过,UNC的没来得及测试。


    • 已编辑 sunkaiwin 2012年7月20日 12:31 纠正错误
    2012年7月20日 12:30
  • 被删除的用户能不能访问还真没试过,UNC的没来得及测试。



    如果普通共享也存在相同问题,那就和DFS完全不相干了。。。
    2012年7月20日 12:47
  • 如果和DFS不相干,那您判断究竟是哪里出了问题呢?我应该从哪里着手去查? 如何解决呢?

    2012年7月21日 1:30
  • 如果和DFS不相干,那您判断究竟是哪里出了问题呢?我应该从哪里着手去查? 如何解决呢?

    先确认完到底和DFS相不相干吧,确认完后说一下。

    后续排错找原因还需要收集更多的信息,之前的信息还不足以下任何结论。

    2012年7月23日 3:18
  • 经过试验测试,确实是DFS的问题,我在该服务器上随便新建了一个普通的共享文件夹,设置并修改权限,结果全部是立即生效,一点问题都没有
    2012年7月23日 5:05
  • 那这些出故障的DFS下的文件夹,是否都是加入DFS复制集的(在两台机器间经NTFSR或DFSR复制的)?
    2012年7月23日 6:01
  • 没有加入任何复制,我的DFS所有共享文件夹根本没有启用复制功能,仅仅是用DFS的分布式文件服务器功能。

    2012年7月23日 8:29
  • 对我改的就是DFS管理器里面目标文件夹的共享权限

    请问,你改动的是 DFS管理器左侧树下的文件夹的“属性”/"高级"/"在DFS文件夹上显式设置查看权限" 吗?

    还是在哪改的?

    2012年7月23日 10:20
  • 对,就是改DFS管理器里面左侧树下文件夹属性的共享权限。

    2012年7月23日 13:48
  • 对,就是改DFS管理器里面左侧树下文件夹属性的共享权限。

    再确认一下,你改的是"在DFS文件夹上显式设置显式查看权限" 吗?

    这不是共享权限!这是“基于访问权限的枚举”(Access-based Enumeration)

    请务必确认

    2012年7月24日 3:30
  • 再次确认,我实在DFS管理器里,改的共享权限,没有在资源管理器里改的文件夹共享权限,这样做有什么问题吗?我一直这样做,没遇到问题,只是最近出问题。

    2012年7月24日 3:55
  • 我还是有点奇怪,怕我所理解的操作和你做的操作不是同一个。。。所以必须再问你一遍。

    你为什么总是强调你修改的是“共享权限”?

    "在DFS文件夹上显式设置显式查看权限"是Access-based Enumeration,这个不是共享权限。你改的就是这个吗?

    2012年7月24日 4:30
  • 嗯,这样就准确了,确实不是我之前问你的 DFS管理器左侧树下的文件夹的“属性”/"高级"/"在DFS文件夹上显式设置查看权限"

    还好再三问你。

    这样的话,你所改的就是 被引用的 共享文件夹 本身的 共享权限,跟Explorer看到或改动的是一回事。

    麻烦再把改动细节描述一下。


    另外,突然补一句,问题发生前,是否刚在服务器上装了什么杀毒软件?杀软是在微软技术支持Case中遇到的比较常见的引起间歇性Access Deny的原因之一。
    • 已编辑 Finy 2012年7月24日 5:44
    2012年7月24日 5:25
  • 经过仔细的测试,我发现,更改权限如果是用户,那立即生效,如果是组,要很久才能生效。啥意思呢,比如我把自己的域账号添加进一个共享文件夹的读取权限,然后尝试访问该文件夹,立马生效,没问题。但当我这个共享文件的权限的主体是一个全局安全组的时候,我在AD里把我的域账号加入这个全局安全组,而这个组被设置为这个共享文件夹权限的主体,结果发现问题出来了,没生效,要等很久,具体时间没计算过,一般下午做完,要第二天早晨来才生效。


    服务器上近来没有安装或卸载过任何软件,没有做过任何的系统设置的改动,仅仅是最近才装了Windows的更新而已,每月一次,你懂的。
    • 已编辑 sunkaiwin 2012年7月24日 6:22 追加
    2012年7月24日 6:20
  • 哈哈,论坛答疑,真相总就是被追问出来的。。。

    你这操作有一点值得推敲:你是在给一个Folder加一个安全组的同时,往这个组里加了一个用户。

    假如你在给一个Folder加一个安全组时,那个用户早就已属于那个组,还会有问题吗?

    这是个关键问题,也可能是Group Access Token延迟被Apply的关键原因。

    2012年7月24日 6:51
  • 答曰:“没问题”

    我有点欣喜,感觉快水落石出了。


    看来就是在改动安全组的用户成员后,很久才生效,这是问题的根本。
    • 已编辑 sunkaiwin 2012年7月24日 7:41 补充说明
    2012年7月24日 7:39
  • 嗯,基本上走对路线了。

    你再回头看看你首帖的问题描述,只字未提“改动安全组的成员”,害人啊。。。

    而且,我相信这个问题不但仅存在于DFS NameSpace下,普通Folder Sharing UNC也是一样的吧?

    也许,这篇文档就可以最终解释并解决你遇到的问题了

    Configure Universal Group Membership Caching in Active Directory

    http://technet.microsoft.com/en-us/magazine/ff797984.aspx

    • 已编辑 Finy 2012年7月24日 8:03
    • 已标记为答案 sunkaiwin 2012年7月24日 8:39
    2012年7月24日 7:56
  • 经过测试,成功解决,但客户端需要注销,重新登录才能生效。

    首先,非常感谢你对我的帮助,你太棒了。

    其次,在我看完这篇文档之后,我enable  Universal Group Membership Caching,但我不明白其中的原理,启用和禁用究竟区别在哪里呢?为什么启用了通用组成员缓存就OK,禁用了就要那么久后才生效这是什么原因呢?


    • 已编辑 sunkaiwin 2012年7月24日 8:41 错别字
    2012年7月24日 8:39
  • 补个更彻底的步骤(也许客户端都不需要注销了):XP的话,拷个klist工具(Win7应该自带了),执行klist purge,然后再访问

    然后再答你的疑 “为什么启用了全局组成员缓存就OK,禁用了就要那么久后才生效这是什么原因呢?”

    你这句话应该反了吧。。。是 “启用后,要等很久才生效”

    文档链接里已经透露了:By default, a refresh occurs every eight hours on each domain controller that’s caching membership locally

    • 已编辑 Finy 2012年7月24日 8:44
    2012年7月24日 8:43
  • 我没说反,我本来没有启用(这个选项没有打钩),现在启用了缓存(打上勾),经过测试才解决的。
    2012年7月24日 14:45
  • 我没说反,我本来没有启用(这个选项没有打钩),现在启用了缓存(打上勾),经过测试才解决的。

    呵呵,有意思,我想我应该没理解错这个Caching功能。。。你这么说来,实际和理论不符了咯?

    你读了文档理解它是怎么样的呢?

    2012年7月25日 2:05
  • Universal membership caching eliminates the dependency on the availability of a global catalog server during logons. When you enable this feature on a domain operating in Windows Server 2003 or higher functional level, any domain controller can resolve logon requests locally without having to go through the global catalog server.
    2012年7月25日 3:59