Post by Henrik LangosPost by Davor VusirPost by steveOn 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,
Steve
Added uid, uidnumber and gidNumber to every account and group.
Resulted in access denied to \\vusir.local\dfs\share and home
directory.
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,
Hi Henrik,
thank you for your mail and sharing your experiences.
Post by Henrik LangosThis pretty much matches my observations with domain based dfs. It's a hit
and miss with lots of poking around in the dark.
For me it was quite straight forward and "just worked". I don't share
the troubles expressed in this thread.
Post by Henrik LangosOccasionally 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.)
I think your suspicions are right. But for me it was (is) mostly
success. The troubles I have encountered, I believe rather depends on
that I run the AD DC and file server at the same host and using a
network bridge for virtualization.
Post by Henrik LangosOnce DFS failed in the observed way, there is no point in logout/login
cycles.
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
business.
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'
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.
I have not experienced neither what have been mentioned on this thread
nor what you write here. But I'm having trouble when the host is
(re)started; Windows complains about non-existing logon servers. I
restart the Samba service, reboot the Windows client and the problem
is gone. The Samba errors are:
WARNING: no network interfaces found
task_server_terminate: [nbtd: no network interfaces configured]
WARNING: no network interfaces found
task_server_terminate: [cldapd: no network interfaces configured]
WARNING: no network interfaces found
task_server_terminate: [kdc: no network interfaces configured]
/usr/local/samba/sbin/samba_dnsupdate: WARNING: no network interfaces found
WARNING: no network interfaces found
task_server_terminate: [nbtd: no network interfaces configured]
WARNING: no network interfaces found
task_server_terminate: [cldapd: no network interfaces configured]
WARNING: no network interfaces found
task_server_terminate: [kdc: no network interfaces configured]
This was not a problem before I configured DFS. Please note that I do
not think that neither Samba as AD DC, file server (the two running on
the same host), DFS nor the network bridge and the Windows client
running as virtual guest per se that is the problem. It is the
combination, all running on the same host, that is the problem.
When the the above combination, AD DC, file server and DFS, starts, it
runs fine! It seems stable.
Post by Henrik LangosIn 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.
Yes. But I think it is worth put some time and energy on.
Regards
Davor
Post by Henrik Langoscheers
-henrik
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba