cifs-utils was upgraded from 7.2-2.fc43 to 7.6-1.fc43 during a routine dnf upgrade on a fc43 server. All samba mounts stopped working. Downgrading the package made all samba mounts available again.

Full disclosure: after debugging for a while without much progress,
I let Claude Code help me out, so treat the following with some amount of skepticism.

---

## Summary

`cifs.upcall` no longer honors the `cruid=` mount option / `creduid=` upcall key field when resolving which Kerberos credential cache to use. It always resolves the *default* ccache for its own real UID (0, since the kernel invokes it as root), regardless of the intended target identity. This makes it impossible to mount `sec=krb5` CIFS shares as multiple different non-root service identities concurrently on one host.

Downgrading `cifs-utils` 7.6-1 → 7.2-2 (same Fedora 43 host, no other
changes) immediately and completely resolves it.

## Environment

- Fedora 43 server, kernel 7.0.13-100.fc43 (also seen on 7.0.12-101.fc43)
- `cifs-utils-7.6-1.fc43` broken; `cifs-utils-7.2-2.fc43` confirmed fine
- `keyutils-1.6.3-6.fc43`, stock `/etc/request-key.d/cifs.spnego.conf`
  (`create cifs.spnego * * /usr/bin/cifs.upcall %k`)
- MIT krb5, `krb5-libs-1.22.2-4.fc43`
- Tried all of `KCM:` (sssd-kcm), `FILE:`, `KEYRING:persistent:%{uid}` as
  `default_ccache_name` — none differentiate the behavior
- 6 independent local service accounts, each with its own keytab, each
  running a `k5start`-managed refresher, each with a valid, non-expired
  TGT in its own ccache at all times. 10 `sec=krb5,seal` mounts total
  against one Samba/CTDB file server, each with `cruid=<local-uid>`
  matching its own account.

## Reproduction

1. Fedora 43, `cifs-utils-7.6-1.fc43`.
2. ≥2 distinct local accounts, each with a valid TGT in its own cache.
3. `mount -t cifs //server/share /mnt -o sec=krb5,cruid=<uid-A>,uid=<uid-A>,...`
   for account A → fails:
   ```
   mount error(126): Required key not available
   ```
   dmesg: `CIFS: VFS: \\server failed to create a new SMB session with Kerberos: -126`
   `cifs.upcall` journal log: `valid TGT is not present in credential cache`
   — despite `klist` (as that user, or via `KRB5CCNAME=<their cache>
   klist`) showing a valid TGT.
4. `dnf downgrade cifs-utils` → 7.2-2.fc43, retry identical mount →
   succeeds.

## Root cause analysis

- `/proc/keys` confirms the kernel correctly passes the target UID in
  the upcall key description, e.g.
  `...sec=krb5;uid=0x3e8;creduid=0x3e8;user=root;pid=...` — kernel-side
  `cruid` plumbing is correct.
- `cifs.upcall` itself does not use `creduid` to select a ccache. Tested
  and all ignored: `KRB5CCNAME=...` set via wrapper or `env`; `-k
  <krb5.conf with default_ccache_name set>`; `-K <keytab>`
  (self-acquire); changing the global `default_ccache_name` between
  `KCM:` / `FILE:` / `KEYRING:`.
- The **only** thing that determines success: whatever ticket happens to
  already be in root's own default ccache (e.g. `/tmp/krb5cc_0`) at
  mount time. Manually `kinit`-ing a given user's TGT into root's cache,
  then running the unmodified stock `cifs.upcall %k`, succeeds only for
  that one identity — confirming root's own resolved cache is the sole
  input, never `creduid`.
- This suggests 7.6 dropped a `creduid`-based UID switch (e.g.
  `setresuid()`/`seteuid()` to `creduid` before the credential-cache
  lookup) that must have existed previously — it's specifically how
  `KCM:` (sssd-kcm, which differentiates callers by control-socket peer
  UID) used to work for multiple concurrent identities.
- Possibly related to the `--no-env-probe`/`-E` behavior documented as
  new/changed in the 7.6 man page.

## Additional oddity (less confidently diagnosed)

Any invocation of `cifs.upcall` 7.6-1 with **any** extra CLI flag (`-k`,
`-K`, `-d`) via a custom `request-key.conf` rule fails the same way, even when the flag's purpose has no bearing on cache resolution. Not isolated further once the downgrade confirmed the fix