Frank Loeffler <frank.loeffler@xxxxxxxxxxx> writes: > As far as I understand, you (can) use a password to obtain a krb5-token, > which is then used for sec=krb5. From a users point of view, you enter > username and password and get access. Whether this is using krb5 and a > token or some other mechanism is usually something a user doesn't even > want to know about. What they know is a username/password combination > and a share name on some remote machine. > If the mechanism happens to be krb5 (isn't that even the default on > Windows shares?), you might need a temporary token, but I wonder if > that "technicality" couldn't be made transparent to the user by default. > This would make mounting Windows shares a lot less 'messy' to users. Yes, from the user point of view, both NTLM and KRB use username/password pair. But in Linux, KRB is a complex system-wide service separate from the kernel, cifs-utils or samba. It is its own project and it requires a /etc/krb5.conf file, proper DNS settings, kinit/klist/... tools etc. All we can do from cifs-utils is expect those to already be in place. Configuring KRB on-the-fly is out of the scope of cifs-utils. > That is unfortunate. However, not even verbose mounting gave me any > indication of what it was that is actually failing. Maybe, before > returning ENOENT, cifs you print something else, possibly at least with > high verbosity/debugging enabled. Do you mean verbose by mounting with -v? If yes, as I said when the mount.cifs program calls the mount() syscall, the kernel can only return a single generic integer code. The mount program cannot tell you much because it doesn't know much. When it mounts with KRB, it just passes sec=krb5 to the kernel. The kernel tries to connect and later on call back userspace (yes, kernel calls userspace, its called "upcalling") program cifs.upcall, which is responsible for finding the krb tickets. That program cannot print to your console, all its logging goes to the syslog. That's why you cannot see much from the mount program. You can read cifs.upcall logs in your system logs, probably with the journalctl command. If you actually want verbosity _from the kernel_ you need to do those steps: https://wiki.samba.org/index.php/Bug_Reporting#cifs.ko You will then find more information after calling mount by looking at the kernel log via the dmesg command. Cheers, -- Aurélien Aptel / SUSE Labs Samba Team GPG: 1839 CB5F 9F5B FB9B AA97 8C99 03C8 A49B 521B D5D3 SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg, DE GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 247165 (AG München)
