Author Topic: Zentyal Development Edition 7.0 - Ubuntu 20.04 File Server partial access  (Read 1140 times)


  • Zen Apprentice
  • *
  • Posts: 4
  • Karma: +0/-0
    • View Profile
Zentyal Development Edition 7.0
Antivirus 7.0.2
FTP 7.0.0
HTTP Proxy 7.0.2
Intrusion Prevention System 7.0.0
Mail 7.0.2
Mail Filter 7.0.0
RADIUS 7.0.0
Virtualization Manager 7.0.1
Web Mail 7.0.0

System Updates - The system components are up to date.
All servers are running in XOA/xcp-ng environment on Dell R720
Primary Domain Controller Zentyal
Secondary Domain Controller is Zentyal also
File Server is a separate Ubuntu 20.04
Windows devices are Windows 10 Pro 22H2 OS Build 19045

Apologies, I'm fairly new to the Ubuntu/Linux world and I am not the original Zentyal installer/configurator here.

I have read Re: AD Stop Working on Windows 11 22H2,35474.msg115368/topicseen.html#msg115368

I just want to inform you that Ubuntu has released the packages that fix the Windows 11 bug with Samba, so if you did not apply any of the proposal workarounds, you just need to update your system packages.

Best regards, Daniel Joven."

This question may answer my issue as I could be confused.

When you say "you just need to update your system packages" do you mean from the Zentyal Software Management\System Updates page within Zentyal, or are we talking about from the OS level?

Details of the issue.

December 16, 2022 late in the afternoon a user complained that they couldn't get to their departmental shared folder. I was able to access it with no issue. Had user reboot PC and upon reboot they could access the file share again.

Monday December 19, none of my users could access File Server by name. \\servername.
\\servername, prior to Dec. 16 would present all shared folders that user has access to.

I was still able to access \\servername and all shared folders on the Ubuntu File Server until mid-day. I then tried \\ip.address and was able to access all shared folders on the file server.
I checked DNS by using test computer that had been offline for awhile which was able to authenticate to the domain with standard domain user.
DNS appeared to be working fine and still appears to be working fine. Windows RSAT DNS tool reports refreshed Timestamps as of this morning.

When I checked package updates I noticed the SMBclient had been updated on the File Server.
I ran package updates on the file server, with no change.
I rolled back to smbclient 14.6, with no change.
I rolled back to I believe, smbclient 14.3 with no change.
I backed up the files from all of the shares on the server and rolled the server back to a snapshot from Oct. 13, 2022 . . . this had no change.
Since I know the File Share was working as expected on December 15, logic tells me, if the issue was with the File Server, it should work when rolled back to the Oct. 13 snapshot.

The other major piece in the puzzle is the Domain Controller(s).

December 19, we saw intermittent loss of service messages on the IP phones which lasted a couple of hours, and then stabilized and we haven't seen that issue since.

I have the secondary DC paused so it doesn't change anything while working on this issue.
I have removed the DNS and Host entries and added them back to the DC.
This seems to have no effect.

Over the past week, net use \\servername of a backup/retired Windows file server has continued to work just fine as well as Windows explorer \\servername\.

I have just attempted net use \\servername to most of my virtual Windows devices and they all complete successfully.

net use \\ubuntufileservername returns  System error 1311, we can't sign you in with this credential because your domain isn't available.

Maybe too much info, maybe not info that's need to assist, but this is the big picture.

Thanks for any assistance.

« Last Edit: December 28, 2022, 06:53:49 pm by roliver »


  • Zen Warrior
  • ***
  • Posts: 197
  • Karma: +15/-0
    • View Profile

When you say "you just need to update your system packages" do you mean from the Zentyal Software Management\System Updates page within Zentyal, or are we talking about from the OS level?

Zentyal manages the OS updates through the tab you mentioned (Zentyal Software Management\System Updates) and that is what he means. You can check if Samba is updated with the fix by running the following command:

Code: [Select]
sudo dpkg -l | grep samba

NOTE: You should get the following version: 2:4.13.17~dfsg-0ubuntu1.20.04.2

Regarding the behaviors you got, a few things came to my mind that may be useful:

1. Did you monitor your Zentyal resources like CPU, RAM, SWAP, and especially, network in/out?
2. When any client report an error, did you check the server log files?

* /var/log/zentyal/zentyal.log
* /var/log/syslog
* /var/log/samba/samba.log

3. Did you check the status of the main services?

Code: [Select]
sudo systemctl status samba-ad-dc bind9

4. According to your answer, you have two domain controllers, did you check what DNS server is answered when the client has an issue?


“This world is ours, and by the Holy Light we will keep it safe, now and forever".


  • Zen Apprentice
  • *
  • Posts: 4
  • Karma: +0/-0
    • View Profile
Thank you for the guidance!
Updated the Virtual Host environment last night.
Updated Xen Orchestra, patched the hosts. LOTS of reboots for the VMs.
Upon ssh to DC1 I received the following message:
  apt list --upgradable
  Listing... Done
  python3-update-manager/focal-updates,focal-updates 1: all [upgradable                                                                                                                                         from: 1:]
  update-manager-core/focal-updates,focal-updates 1: all [upgradable fr                                                                                                                                  om: 1:]

I logged into the Zentyal console on DC1 and applied the Software Updates from there.

DC2 did not prompt for updates, even after refreshing the update list from the Zentyal console.

On DC1 which is our "Primary".

sudo dpkg -l grep samba
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name           Version                         Architecture Description
ii  grep           3.4-1                           amd64        GNU grep, egrep>
ii  samba          2:4.13.17~dfsg-0ubuntu1.20.04.2 amd64        SMB/CIFS file,

1. Zentyal Resources: The DCs are in a Xen-Orchestra/xcp-ng virtual environment.
I did not notice anything in the VM management console "Performance" tab to indicate high CPU or RAM utilization.

2. Server log files: I'm just getting into the Ubuntu/Linux world so I plead ignorance. I certainly know to check logs, I just wasn't sure what to look for at that point in time.
Checking the suggested logs this morning.
  zentyal.log - at the bottom of the log at the time of capture
      2023/01/04 09:21:44 ERROR> EBox::Sudo::_rootError - root command LANG=C  /usr/sbin/ejabberdctl status failed
        it appears the majority of issues are related to jabber.

  syslog - I see some update denied messages paired with invalid signature: TSIG

  samba.log - I see some "Failed to connect host DC2.IP on port 135 in regard to resolve_lmhosts.

3. Status of main services:
    samba-ad-dc.service active(running)
        Status: "samba: ready to serve connections..."
    named.service - BIND Domain Name Server active (running)

4.  I know we have had an issue with pulling group policy if set logonserver returns DC2. That's one of the first things I noticed 6 months ago when I started here. I have attempted to set logonserver=DC1 on all of the user devices so they will pull group policy on login.

Lots of 'opportunities' for success in this environment.  :)

Thank you again!
« Last Edit: January 04, 2023, 08:13:49 pm by roliver »


  • Zen Warrior
  • ***
  • Posts: 197
  • Karma: +15/-0
    • View Profile

The only thing that came to my mind at this moment is:

When someone gets the DNS/DC issue, make a DNS query to identify what DNS server and the domain controller are using. And in case it is using Zentyal, then, analyze the following log files:

* /var/log/zentyal/zentyal.log
* /var/log/syslog
* /var/log/samba/samba.log


“This world is ours, and by the Holy Light we will keep it safe, now and forever".