File Server Problems

Even when setting up a file server, you'll find pitfalls that keep a file server from starting, or at least providing its services. At this point, I'll look at what can happen when setting up a file server. I will not go into the installation of the packages; this explanation is only about the service configuration. The distribution you are using to set up the file server does not matter.

To begin, you should always complete the basic configuration of the file server; that is, you only configure the global area and execute a domain join. Once you have done this, only configure the shares. After you have prepared smb.conf, start the first attempt to integrate the server into the domain. You will see the message in Listing 5.

root@fs-01:~# net ads join -U administrator
Enter administrator's password:
Failed to join domain: failed to lookup DC info for domain 'EXAMPLE' over rpc: {Operation Failed} The requested operation was unsuccessful.

Checking the Name Server

The error message in Listing 5 indicates that the DC could not be found. First, test whether you can resolve the DC name and whether you can ping the DC. In this case, the name cannot be resolved. A look at the /etc/resolv.conf file shows that no DC is registered as the name server. Make sure at least one DC is set up as the name server in the configuration.

It is better to enter two DCs as name servers; in this case, the second DC can take over the role of the name server if the first DC fails or has to be taken off the network for a short time. File servers in particular should always have at least two name servers configured, so they still work even if one name server fails.

If you already have entered the IP address of at least one DC as the name server but still receive the error message from Listing 6 on trying to join, you need to check the /etc/hosts file to see whether it contains the correct hostname with the correct IP address. The FQDN is correct if the command hostname -f returns the expected value. After modifying the entry in /etc/hosts, you can again try to join the file server to the domain. If you get the error message from Listing 7 now, the error is not caused by the file server; rather, the DNS server has problems with dynamic updates.

root@fs-01:~# net ads join -U administrator
root@fs-01:~# net ads join -U administrator
Enter administrator's password:
Using short domain name -- EXAMPLE
Joined 'FS-01' to dns domain 'example.net'
No DNS domain configured for fs-01. Unable to perform DNS Update.
DNS update failed: NT_STATUS_INVALID_PARAMETE

root@fs-01:~# net ads join -U administrator
Enter administrator's password:
Using short domain name -- EXAMPLE
Joined 'FS-01' to dns domain 'example.net
DNS Update for fs-01.example.net failed: ERROR_DNS_UPDATE_FAILED
DNS update failed: NT_STATUS_UNSUCCESSFUL

To see whether dynamic updates are working, test the DCs:

samba_dnsupdate --verbose --all-names

You will see output all entries on the DNS server. Listing 8 shows an excerpt from the output; the error message at the end is important. Here, the DNS entry update does not seem to work. To correct this error, proceed as described in Listing 9.

root@addc-01:~# samba_dnsupdate --verbose --all-names
IPs: ['192.168.56.66']
force update: A addc-01.example.net 192.168.56.66
force update: NS example.net addc-01.example.net
force update: NS _msdcs.example.net addc-01.example.net
force update: A example.net 192.168.56.66
...
update failed: NOTAUTH
Failed nsupdate: 2
Failed update of 29 entries

root@addc-01:~# samba_upgradedns --dns-backend=BIND9_DLZ
Reading domain information
DNS accounts already exist
No zone file /var/lib/samba/bind-dns/dns/EXAMPLE.NET.zone
DNS records will be automatically created
DNS partitions already exist
dns-addc-01 account already exists
...
root@addc-01:~# systemctl restart bind9

The command

samba_dnsupdate --verbose --all-names

should now run without errors. Check the updating on all your DCs and fix the error on other DCs, if necessary. If the test command returns an update failed: NOT-AUTH error, something is wrong with the authentication of BIND9 via Kerberos in the Active Directory. Check whether you have entered the following line correctly in the /etc/bind/named.conf.options file:

tkey-gssapi-keytab "/var/lib/samba/private/dns.keytab";

If the entry exists, the BIND9 user might still not be able to read the keytab file. Checking the authorizations and setting the appropriate permissions should also fix the error.

Now you can start the join on the file server again, only, continue your tests once the output of the command looks like Listing 10.

root@fs-01:~# net ads join -U administrator
Enter administrator's password:
Using short domain name -- EXAMPLE
Joined 'FS-01' to dns domain 'example.net'
root@fs-01:~# net ads testjoin
Join is OK

User Mapping Problems

After modifying the /etc/nsswitch.conf file to use winbind, you might notice that although the user is displayed with

wbinfo -i <AD-User>

the mapping to the unique identifier (UID) does not seem to work (Listing 11).

root@fs-01:~# wbinfo -n test-u1
S-1-5-21-831035265-3946242641-4171447920-1408 SID_USER (1)
root@fs-01:~# wbinfo -i test-u1
failed to call wbcGetpwnam: WBC_ERR_DOMAIN_NOT_FOUND
Could not get info for user test-u1
root@fs-01:~# getent passwd test-u1
_

Unfortunately, this error message is absolutely misleading. The domain is there; you can prove this by listing the users with wbinfo -n test-u1; wbinfo -p is also successful. The Winbind service seems to be running, and the domain is reachable. The problem can thus only be the ID mapping settings in the smb.conf file. The settings for the ID mapping in the file are:

idmap config * : range = 10000 - 19999
idmap config EXAMPLE : backend = rid
idmap config EXAMPLE : range = 1000 - 1999

You can see here that the range for the EXAMPLE domain is too small. The UID is calculated from the relative identifier (RID) of the user: In the case of the test-u1 user 1408 , adding the first value from the range (i.e., 1000 ) results in a value of 2408 . This value is outside the range of 1999 .

Therefore, the user can no longer be mapped. If you specify the range, be sure to select a value that is large enough. Especially if you have migrated to Samba 3 with openLDAP, the RID can have a value greater than 100,000. After adjusting the range, stop the Winbind service, run the net cache flush command, and restart the service.

Another error that can occur when configuring ID mapping is that the second specified value is smaller than the first value. Then, the user may be displayed with:

wbinfo -i <AD-User>

However, the UID does not match the user's RID. Therefore, always check whether the values of the UID for a user match the RID.