Shares not working anymore

Hello again,

a strange new prob occurs in my freshly setup domain which worked well for 2 weeks(UCS4.3):
now login on win clients works, but shares are not accessible. Passwords are asked for, but are not accepted.
But when I log into shares with another username, which is
olddomain\username instead of newdomain\username,
access is granted althuogh with messed up permissions.
Also some gpos don’t work anymore.
DNS seems to be the problem. There was one short moment, when the old DC-Master was up again in the same network ( the vm was started accidentally), maybe this confused dns,
but I Cannot find wrong dns entries
Does anyone have an idea?
thanks

bernhard

Hi,

thanks for posting in English for our International users- I just updated the thread title…

Pelase tell us:
ucr get dns/backend
Restart dns (succesfull?):
systemctl restart bind9
Restart Samba:
/etc/init.d/samba restart

As you stated about an old domain do they use the same DNS-Domain?

/CV

Thank you for your quick response.

root@dc1:~# ucr get dns/backend
samba4
root@dc1:~#

all servers (dc1,dc2,member) have been restartet completely.

The new domain uses the same network-IPs as the old one but different FQDNs.
Some old programs refer to servername and -adress, so I had to use identical servername and IP for the memberserver. Like this:
old member: 10.0.0.20 member.company.intranet
new member: 10.0.0.20 member.corp.int

At no time the memberservers run in parallel, of course. Only the old master came up for some minutes again.

My first post has to be corrected: with that old login to the memberserver the shares can be made visible but not accessable. The only way to access shares is typing the IP into the address bar of windows explorer. Everything else needing a proper DNS is not working, although from Windows I can ping all servers by name or IP successfully.

Here are the outputs of the other commands you have asked for:

root@dc1:~# systemctl restart bind9
Job for bind9.service failed because the control process exited with error code.
See "systemctl status bind9.service" and "journalctl -xe" for details.
root@dc1:~#
root@dc1:~# systemctl restart bind9
Job for bind9.service failed because the control process exited with error code.
See "systemctl status bind9.service" and "journalctl -xe" for details.
root@dc1:~# ^C
root@dc1:~# ^C
root@dc1:~# "systemctl status bind9.service
> ^C
root@dc1:~# systemctl status bind9.service
● bind9.service - BIND Domain Name Server with samba4 backend
   Loaded: loaded (/lib/systemd/system/bind9.service; enabled; vendor preset: enabled)
  Drop-In: /etc/systemd/system/bind9.service.d
           └─10-configure-backend.conf
   Active: activating (start-post) (Result: exit-code) since Mon 2019-04-01 14:45:43 CEST; 12s ago
     Docs: man:named(8)
  Process: 23728 ExecStop=/usr/lib/univention-bind/samba4 stop (code=exited, status=0/SUCCESS)
  Process: 24481 ExecStart=/usr/lib/univention-bind/samba4 start (code=exited, status=1/FAILURE)
  Process: 24478 ExecStartPre=/bin/systemctl stop univention-bind-ldap.service (code=exited, status=0/SUCCESS)
 Main PID: 24481 (code=exited, status=1/FAILURE); Control PID: 24482 (samba4)
    Tasks: 4 (limit: 4915)
   Memory: 1.0M
      CPU: 244ms
   CGroup: /system.slice/bind9.service
           └─control
             ├─24482 /bin/sh /usr/lib/univention-bind/samba4 wait-for-startup
             ├─24483 /usr/bin/timeout 30 /bin/sh -c until rndc -p 953 status | grep --quiet 'server is up and running'; do sl
             ├─24485 /bin/sh -c until rndc -p 953 status | grep --quiet 'server is up and running'; do sleep 1; done
             └─24597 sleep 1

Apr 01 14:45:50 dc1 samba4[24482]: rndc: connect failed: 127.0.0.1#953: connection refused
Apr 01 14:45:51 dc1 samba4[24482]: rndc: connect failed: 127.0.0.1#953: connection refused
Apr 01 14:45:52 dc1 samba4[24482]: rndc: connect failed: 127.0.0.1#953: connection refused
Apr 01 14:45:53 dc1 samba4[24482]: rndc: connect failed: 127.0.0.1#953: connection refused
Apr 01 14:45:54 dc1 samba4[24482]: rndc: connect failed: 127.0.0.1#953: connection refused
Apr 01 14:45:55 dc1 samba4[24482]: rndc: connect failed: 127.0.0.1#953: connection refused
Apr 01 14:45:56 dc1 samba4[24482]: rndc: connect failed: 127.0.0.1#953: connection refused
Apr 01 14:45:57 dc1 samba4[24482]: rndc: connect failed: 127.0.0.1#953: connection refused
Apr 01 14:45:58 dc1 samba4[24482]: rndc: connect failed: 127.0.0.1#953: connection refused
Apr 01 14:45:59 dc1 samba4[24482]: rndc: connect failed: 127.0.0.1#953: connection refused
Apr 01 14:46:00 dc1 samba4[24482]: rndc: connect failed: 127.0.0.1#953: connection refused
Apr 01 14:46:01 dc1 samba4[24482]: rndc: connect failed: 127.0.0.1#953: connection refused

root@dc1:~# journalctl -xe
Apr 01 14:47:14 dc1 systemd[1]: Stopped BIND Domain Name Server with samba4 backend.
-- Subject: Unit bind9.service has finished shutting down
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- Unit bind9.service has finished shutting down.
Apr 01 14:47:14 dc1 systemd[1]: Starting BIND Domain Name Server with samba4 backend...
-- Subject: Unit bind9.service has begun start-up
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- Unit bind9.service has begun starting up.
Apr 01 14:47:14 dc1 samba4[25182]: rndc: connect failed: 127.0.0.1#953: connection refused
Apr 01 14:47:14 dc1 named[25181]: starting BIND 9.10.3-P4-Univention <id:ebd72b3> -c /etc/bind/named.conf.samba4 -f -d 0
Apr 01 14:47:14 dc1 named[25181]: built with '--prefix=/usr' '--mandir=/usr/share/man' '--libdir=/usr/lib/x86_64-linux-gnu' '
Apr 01 14:47:14 dc1 named[25181]: ----------------------------------------------------
Apr 01 14:47:14 dc1 named[25181]: BIND 9 is maintained by Internet Systems Consortium,
Apr 01 14:47:14 dc1 named[25181]: Inc. (ISC), a non-profit 501(c)(3) public-benefit
Apr 01 14:47:14 dc1 named[25181]: corporation.  Support and training for BIND 9 are
Apr 01 14:47:14 dc1 named[25181]: available at https://www.isc.org/support
Apr 01 14:47:14 dc1 named[25181]: ----------------------------------------------------
Apr 01 14:47:14 dc1 named[25181]: adjusted limit on open files from 4096 to 1048576
Apr 01 14:47:14 dc1 named[25181]: found 4 CPUs, using 4 worker threads
Apr 01 14:47:14 dc1 named[25181]: using 2 UDP listeners per interface
Apr 01 14:47:14 dc1 named[25181]: using up to 4096 sockets
Apr 01 14:47:14 dc1 named[25181]: loading configuration from '/etc/bind/named.conf.samba4'
Apr 01 14:47:14 dc1 named[25181]: /etc/bind/named.conf.samba4:19: invalid prefix length '255'
Apr 01 14:47:14 dc1 named[25181]: loading configuration: out of range
Apr 01 14:47:14 dc1 named[25181]: exiting (due to fatal error)
Apr 01 14:47:14 dc1 systemd[1]: bind9.service: Main process exited, code=exited, status=1/FAILURE
Apr 01 14:47:15 dc1 samba4[25182]: rndc: connect failed: 127.0.0.1#953: connection refused
Apr 01 14:47:16 dc1 samba4[25182]: rndc: connect failed: 127.0.0.1#953: connection refused
Apr 01 14:47:17 dc1 samba4[25182]: rndc: connect failed: 127.0.0.1#953: connection refused
Apr 01 14:47:18 dc1 samba4[25182]: rndc: connect failed: 127.0.0.1#953: connection refused
Apr 01 14:47:19 dc1 samba4[25182]: rndc: connect failed: 127.0.0.1#953: connection refused
Apr 01 14:47:20 dc1 samba4[25182]: rndc: connect failed: 127.0.0.1#953: connection refused
Apr 01 14:47:21 dc1 samba4[25182]: rndc: connect failed: 127.0.0.1#953: connection refused
Apr 01 14:47:22 dc1 samba4[25182]: rndc: connect failed: 127.0.0.1#953: connection refused
Apr 01 14:47:23 dc1 samba4[25182]: rndc: connect failed: 127.0.0.1#953: connection refused
Apr 01 14:47:24 dc1 samba4[25182]: rndc: connect failed: 127.0.0.1#953: connection refused
Apr 01 14:47:25 dc1 samba4[25182]: rndc: connect failed: 127.0.0.1#953: connection refused
Apr 01 14:47:26 dc1 samba4[25182]: rndc: connect failed: 127.0.0.1#953: connection refused
Apr 01 14:47:27 dc1 samba4[25182]: rndc: connect failed: 127.0.0.1#953: connection refused
Apr 01 14:47:28 dc1 samba4[25182]: rndc: connect failed: 127.0.0.1#953: connection refused
Apr 01 14:47:29 dc1 samba4[25182]: rndc: connect failed: 127.0.0.1#953: connection refused
Apr 01 14:47:30 dc1 samba4[25182]: rndc: connect failed: 127.0.0.1#953: connection refused
lines 1268-1313/1313 (END)

restarting samba didn’t change the situation.

Hey,

looks like you have some bogus data in some of your UCR variables. Please post the output of the following:

ucr get dns/allow/query/cache
ucr search --brief --value 255

My guess is that you’ve set something like dns/allow/query/cache=10.1.2.0/255.255.255.0 (subnet mask syntax) while you’d have to use dns/allow/query/cache=10.1.2.0/24 (prefix length syntax).

Moin Moin,

actually I did find this variable before and changed it to any.

root@dc1:~# ucr get dns/allow/query/cache
any
root@dc1:~# ucr search --brief --value 255
root@dc1:~#

The second command doesn’t give back any result.
Using ping or nslookup dns seems to work. But accessing a share by hostname is impossible. Even with the correct credentials entered in the popping up authentication dialogue.

So is your bind9.service starting again now after the change to the variable?

I also just re-read your original post and am thoroughly confused about your situation. Care to elaborate a bit? You’re talking about having reinstalled the server, you’re talking about an old and a new domain name, that access with the old domain name is supposedly working…

What was the situation before you reinstalled? How did you reinstall? What are the relevant domain names (both the old & the new one)? Are there any other UCS servers beside the DC Master? Did you join all Windows machines to the new domain after the reinstallation?

Hi Mr. Bunkus,

I couldn’t wait for a solution, so I reinstalled everything again last night(s).
Just for completeness:
A couple of weeks ago a prob with the udn replication already forced me to do that.
That means setting up another dc with different domain name and another memberserver with different domain name but identical hostname. I tried to avoid running both dcs at the same time, because they were in the same IP range, but it happened by accident. Anyway I am unsure, wether this had any influence on the difficulties that occured – just found no other incident, that could have to do with them. All Win clients were joined to the respective new domain. Concerning bind9, I cannot answer your question anymore, because the vm is deleted.
I am still wondering what made my systems so fragile. It run very well for more than one year, but after moving the fileserver to a ucs system and integration as member in the domain, the problems arose while nothing else was changed with the dcs. To avoid further trouble with communication between the machines I now put dc and shares on one and the same vm. This simplification and a full backup of the vm to a nas every night (takes hours, slow network, so I didn’t do that yet) will make things easier, I hope.

Mastodon