[Samba] domain-based DFS ?
davortvusir at gmail.com
Sat Jul 5 22:14:08 MDT 2014
2014-07-02 18:48 GMT+02:00 Henrik Langos <hlangos-samba at innominate.com>:
> On 07/02/14 09:28, Davor Vusir wrote:
>>> On our config it treats the domain as the name of the server! Anyway,
>>> thanks for your time. We can't spend any longer with this as we are looking
>>> for a solution.
>>> Thanks again,
>> Added uid, uidnumber and gidNumber to every account and group.
>> Resulted in access denied to \\vusir.local\dfs\share and home
>> Commented 'idmap_ldb:use rfc2307 = yes'. No change.
>> Removed uid, uidNumber and gidNumber from relevant accounts and access
>> groups. No change.
>> Removed uid, uidNumber and gidNumber from all accounts and access
>> Groups. No change.
>> Reactivated 'idmap_ldb:use rfc2307 = yes'. No change.
>> A couple of restarts of the Windows 7 client, AD DC restarts and a
>> server reboot. Back in business.
> Hi Davor,
> This pretty much matches my observations with domain based dfs. It's a hit
> and miss with lots of poking around in the dark.
> Occasionally it works and all looks very nice, but then on the next login it
> might fail again. For me it was mostly failing.
> (But then again I suspect it had to do with my removing one of the AD DCs
> and downgrading it to a normal member server. I've seen the former AD pop up
> in one of the DFS tabs as dfs root even though it wasn't a DC any more.)
> Once DFS failed in the observed way, there is no point in logout/login
> The only thing that *sometimes* helps is a complete reboot of the client and
> hoping for the best.
> This makes debugging the problem a very frustrating and time consuming
> Also smbclient and windows 7 show very different behavior.
> In smbclient I can always at least see the dfs directory but access to the
> visible shares will fail.
> $ smbclient -U sample12 '\\domain.local\dfs'
> Enter sample12's password:
> Domain=[DOMAIN] OS=[Unix] Server=[Samba 4.1.9-Debian]
> smb: \> ls
> . D 0 Mon Jun 30 20:53:09 2014
> .. D 0 Thu Jun 26 13:17:10 2014
> test2 D 0 Mon Jun 30 18:08:11 2014
> test D 0 Mon Jun 30 10:20:23 2014
> 64514 blocks of size 32768. 30984 blocks available
> smb: \> ls test
> session setup failed: NT_STATUS_LOGON_FAILURE
> Unable to follow dfs referral [\shares01\test]
> do_list: [\test] NT_STATUS_PATH_NOT_COVERED
> smb: \>
> In Windows 7 I can see the dfs share when I go to \\domain.local\ but
> changing into that \\domain.local\dfs share results in an error.
> In contrast to this, access via \\addchost.domain.local\dfs works reliably
> from Windows and smbclient alike.
> Using this form I can even use smbclient with Kerberos authentication.
> (which fails for "domain.local" as there is no service principle for
> cfis/domain.local at DOMAIN.LOCAL in the Kerberos database.)
> I'll put that topic away for now.
you're right. Eventually it decays to what you describe. Eroding,
maybe. It's very annoying, because if it works with the netlogon and
sysvol shares, it has to work with a domain-based DFS.
Below are the latest changes I made to smb.conf.
I also configured WINS-server on the client and enabled NetBIOS in the
TCP/IP Control Panel.
When I enabled NetBIOS in the TCP/IP Control Panel I got the access
error. I can't recall how I fixed that but it might be a good idea to
edit ACLs on the DFS share.
And while you're at it, why not add WINS...
I'm wondering how much I'm violating the AD DC...
Perhaps it was the 'allow insecure wide links = yes' that made it
work. Well... it's still working.
# Global parameters
host msdfs = yes
interfaces = 192.168.1.3/24
bind interfaces only = yes
wins support = yes
wins server = 192.168.1.3
allow insecure wide links = yes
path = /data/files
comment = "Här finns allt!"
read only = No
vfs objects = acl_xattr
msdfs root = yes
> To unsubscribe from this list go to the following URL and read the
> instructions: https://lists.samba.org/mailman/options/samba
More information about the samba