[Samba] First use of cd ~user fails on systems using winbind

[Jason Keltz]

On Thu, 19 Oct 2023 15:34:46 -0400
Jason Keltz via samba <samba at lists.samba.org> wrote:

> Hi.
>
> I'm running the latest Samba 4.18 on our dc (Linux - Rocky 8.8), and
> the clients are running the latest 4.17 (Linux - Rocky 8.8) to be
> upgraded to 4.18 soon.
>
> I've noticed an issue for awhile that is really quite strange and
> wonder if anyone has any thoughts on this.
>
> Samba/Kerberos auth has been setup and working for quite a long time,
> and I don't think the configuration of Samba really has anything to
> do with this issue, but just wondering if someone has seen this issue.
>
> Once I login to my system as me (GNOME) and open a terminal, if I try
> to "cd ~jas" (my user ID) I get: "Unknown user: jas".
>
> Any time after the first fail, I can "cd ~jas" and it works fine.
>
> If open a new terminal, and run "whoami" right away, it says "jas",
> and then try "cd ~jas", again the first time it reports: Unknown
> user: jas, and the next cd ~jas works without error.
>
> If I open a new terminal, and run "cd /cs/home/jas" which is what
> ~jas would be expanded to then it works, but again if I follow that
> with "cd ~jas" I get: Unknown user: jas the first time.  Do it again
> and it works.
>
> If I open a terminal, and run "id", then I get back the proper id
> info exactly as I expect, but again, run "cd ~jas" and I get "User
> unknown: jas" the first time.
>
> If I open a terminal, and run "echo ~jas" it returns the "Unknown
> user: jas", and if I echo ~jas again it works.
>
> On the other hand, if I open a terminal and immediately run "echo ~"
> then it returns "/cs/home/jas" and if I type "cd ~" it works, but if
> I type "cd ~jas" it again returns Unknown user: jas the first time.
>
> In /etc/nsswitch.conf I do have (among other lines):
>
> passwd:      files winbind systemd
> shadow:     files
> group:       files winbind systemd
>
>   I even tried removing "files" from the passwd line, and got the
> same result.
>
> Any thoughts?  I'm guessing potential OS bug? but surely I wouldn't
> be the first person to recognize it.
>
> Jason.
>
>

I have seen something like this, but it was a number of years ago and
was caused by winbind not starting at boot, though I doubt this is your
problem.

It just so happens that I have Samba running on Rocky 8 in a VM,
problem is, everything works for myself.

Where did you get the Samba packages for a DC on Rocky from ?

Can you please post the smb.conf from the client, easiest is to post
the output of 'testparm -s'

Rowland

---

Hi Rowland,

We build samba ourselves.

winbind definately starts at boot.

winbind.service is as follows:

[Unit]
Description=Samba Winbind Daemon
Wants=network-online.target nss-lookup.target nss-user-lookup.target
After=network-online.target nss-lookup.target nss-user-lookup.target

[Service]
Environment="PATH=/opt/samba/bin:/opt/samba/sbin:/xsys/bin:/xsys/sbin:/sbin:/bin:/usr/sbin:/usr/bin"
Type=forking
#NotifyAccess=all
ExecStart=/opt/samba/sbin/winbindd -D -s /etc/samba/smb.conf
ExecReload=/usr/bin/kill -HUP $MAINPID
PIDFile=/var/run/winbindd.pid
LimitNOFILE=16384
LimitCORE=infinity
Restart=always
RestartSec=5s

[Install]
WantedBy=multi-user.target

---

The output of "testparm -s" on the client is as follows:

% /opt/samba/bin/testparm -s
Load smb config files from /etc/samba/smb.conf
Loaded services file OK.
Weak crypto is allowed by GnuTLS (e.g. NTLM as a compatibility fallback)

Server role: ROLE_DOMAIN_MEMBER

# Global parameters
[global]
      debug pid = Yes
      debug uid = Yes
      dedicated keytab file = /etc/krb5.keytab
      disable spoolss = Yes
      kerberos method = secrets and keytab
      load printers = No
      max log size = 0
      printcap name = /dev/null
      realm = AD.EECS.YORKU.CA
      security = ADS
      template homedir = /eecs/home/%U
      template shell = /bin/bash
      username map = /xconf/samba/usermap
      winbind nss info = rfc2307
      winbind offline logon = Yes
      winbind refresh tickets = Yes
      winbind use default domain = Yes
      winbind use krb5 enterprise principals = No
      workgroup = EECSYORKUCA
      idmap config eecsyorkuca : unix_nss_info = yes
      idmap config eecsyorkuca : unix_primary_group = yes
      idmap config eecsyorkuca : range = 1000-999999
      idmap config eecsyorkuca : schema_mode = rfc2307
      idmap config eecsyorkuca : backend = ad
      idmap config * : range = 1000000-1999999
      idmap config * : backend = tdb
      map acl inherit = Yes
      printing = bsd
      vfs objects = acl_xattr

----

All of this has been working for a very long time.  What I can't remember is when I started having this particular problem.  It's been awhile though..

I feel like it has something to do with the system used to do the lookup, but can't think of any specific thing to try to debug that.

Jason.