Hi,
I'm trying to use smb:// URLs with gvfs-mount and/or similar desktop functionality to access SMB shares on different servers that support different protocol versions and features. With some of the servers, mount will fail with a default configuration, but I have been able to make it work by editing some of the "client" options in /etc/samba/smb.conf. The problem is, those changes will cause the operation to fail on other servers; I can't seem to find a combination of settings where all shares will work.
Does anyone know if there is an alternative way to specify client options that will apply to only specific URLs/shares, and not everything of SMB type? Note that I might be able to get by if I could set the "max protocol" individually for the different file-systems or URLs.
I known that I might use mount.cifs and related "fstab" entries as an alternative, but its password handling seems a lot less convenient.
I'm on a CentOS 7 system where all updates had been applied as of a few days ago.
Thanks,
- Toralf
On Thu, 21 Jun 2018, Toralf Lund wrote:
I known that I might use mount.cifs and related "fstab" entries as an alternative, but its password handling seems a lot less convenient.
If you're in an AD environment, you can probably do nicely with mount.cifs:
sec=krb5,multiuser
That way you don't have to deal with usernames/passwords at all.
jh
On 06/21/2018 05:09 AM, John Hodrien wrote:
On Thu, 21 Jun 2018, Toralf Lund wrote:
I known that I might use mount.cifs and related "fstab" entries as an alternative, but its password handling seems a lot less convenient.
If you're in an AD environment, you can probably do nicely with mount.cifs: sec=krb5,multiuser That way you don't have to deal with usernames/passwords at all.
Interesting. Seems like a lot of setup, but it's interesting. I didn't know SMB supported this:
On Thu, 21 Jun 2018, Gordon Messmer wrote:
On 06/21/2018 05:09 AM, John Hodrien wrote:
On Thu, 21 Jun 2018, Toralf Lund wrote:
I known that I might use mount.cifs and related "fstab" entries as an alternative, but its password handling seems a lot less convenient.
If you're in an AD environment, you can probably do nicely with mount.cifs: sec=krb5,multiuser That way you don't have to deal with usernames/passwords at all.
Interesting. Seems like a lot of setup, but it's interesting. I didn't know SMB supported this:
That article makes it sound a whole lot harder than it is, as almost all of that is pre done in later versions of CentOS.
You don't have to configure the upcall stuff as it's already done, you don't need to generate a credential cache for root as it can just use the keytab, and if you've already setup a machine to talk to AD with SSSD you've probably done everything else.
Paired with wildcard automount entries, and you end up in a very usable setup with minimal config.
jh
On 21/06/18 14:09, John Hodrien wrote:
On Thu, 21 Jun 2018, Toralf Lund wrote:
I known that I might use mount.cifs and related "fstab" entries as an alternative, but its password handling seems a lot less convenient.
If you're in an AD environment, you can probably do nicely with mount.cifs:
Well, I'm not. Or the CentOS machine is not configured for it, anyway. Might be possible to do, but I'm not entirely sure it would be worth the effort.
- Toralf
sec=krb5,multiuser
That way you don't have to deal with usernames/passwords at all.
jh _______________________________________________ CentOS mailing list CentOS@centos.org https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.centos.org_mailma...
On Fri, Jun 22, 2018 at 03:43:56PM +0200, Toralf Lund wrote:
Well, I'm not. Or the CentOS machine is not configured for it, anyway. Might be possible to do, but I'm not entirely sure it would be worth the effort.
All you'd need is to use AD's kerberos realm for authentication and have a username that matches the AD name.
(And honestly, if you are someplace with AD you probably should be using at least the kerberos component, and possibly binding to the domain so you can use it's account managemnt too. You just need patient AD admins.)
On Fri, 22 Jun 2018, Jonathan Billings wrote:
On Fri, Jun 22, 2018 at 03:43:56PM +0200, Toralf Lund wrote:
Well, I'm not. Or the CentOS machine is not configured for it, anyway. Might be possible to do, but I'm not entirely sure it would be worth the effort.
All you'd need is to use AD's kerberos realm for authentication and have a username that matches the AD name.
You need more than that to do it securely, as you need a keytab.
(And honestly, if you are someplace with AD you probably should be using at least the kerberos component, and possibly binding to the domain so you can use it's account managemnt too. You just need patient AD admins.)
As long a s you have rights to add machines to the domain, you shouldn't need to bother the admins at all, unless you need to modify delegation permissions, which only really affect windows clients anyway.
jh