Specifying Different Options For Different ” Smb” Type Gvfs Mount

Home » CentOS » Specifying Different Options For Different ” Smb” Type Gvfs Mount
CentOS 7 Comments

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

7 thoughts on - Specifying Different Options For Different ” Smb” Type Gvfs Mount

  • 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

  • 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

  • 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

  • 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.)

  • You need more than that to do it securely, as you need a keytab.

    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