Recently we upgraded from cifs-utils-7.0-5.el9.x86_64 to cifs-utils-7.2-1.el9.x86_64 and had some trouble with the new `upcall_target` functionality [1]. We tried setting `upcall_target=mount` in our mount options according to the mount.cifs manpage but we got errors that it was an unknown mount parameter [2].

Since the changes were in cifs.upcall.c, we then attempted to use `cifs_upcall --upcall_target=mount` instead but we ran into more unrecognized options [3]. Skimming the code, it looks like long/short options were never added to `cifs.upcall.c`. 

[1] https://git.samba.org/?p=cifs-utils.git;a=commitdiff;h=89b679228cc1be9739d54203d28289b03352c174

[2]

# mount -t cifs //<MY SAMBA SHARE>  /cifs -o upcall_target=mount,cruid=0,sec=krb5i,multiuser
mount error(22): Invalid argument
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg)
# journalctl -e | tail -n1
May 23 12:33:02 kernel: cifs: Unknown parameter 'upcall_target'
# man mount.cifs | grep -A5 upcall_target
       upcall_target=arg
              Determines  the  namespace in which upcalls from the SMB filesystem should be handled.  Allowed values are: - mount - Resolve
              upcalls to the host namespace.  - app - Resolve upcalls in the namespace of the calling thread (application). Default  value
              is app.  This option is useful in environments like Kubernetes, where the mount may be performed by a driver pod on behalf of
              an application running in a separate container. It ensures that Kerberos credentials and other  user-specific  data are  ac‐
              cessed  in  the  correct  namespace.  By specifying app, upcalls can be resolved in the application's namespace, ensuring the

[3]

May 23 16:15:52 cifs.upcall[381575]: unknown option: ?
May 23 16:15:52 cifs.upcall[381575]: Negating key
May 23 16:15:52 cifs.upcall[381575]: Exit status 1