Are we mixing module arguments and mount options in the same mechanism, and should we? Module arguments are global in the sense that we only have a single instance of the module loaded into the kernel and its settings apply to all client connections and mounts. For module arguments, such as disable smb1 completely we already have /etc/modprobe.d and it should be sufficient? It is already persistent and it controls the arguments for loading the module. I see a hypothetical /etc/cifsmount.conf as orthogonal to this. This should not be about module arguments but rather mount options. Either global mount options or mount options that automatically apply (and override the user command line) on a per server or mountpoint basis. It could be used to say things like : * only allow SMB2+ mounts... (even if the module itself allows smb1) * use smb1 and posix for servers a/b/c... ... and mount.cifs would parse this file and add the arguments that were missing automatically. regards ronnie sahlberg ----- Original Message ----- From: "Steve French" <smfrench@xxxxxxxxx> To: "Kenneth Dsouza" <kdsouza@xxxxxxxxxx> Cc: "CIFS" <linux-cifs@xxxxxxxxxxxxxxx> Sent: Friday, 29 June, 2018 1:46:35 PM Subject: Re: Can we have cifsmount.conf? since there are only about 20 of the 90 cifs mount options that are needed for 99% of the cases this tool may not be that bad to create - and of course for extra-credit/bonus-points a GUI mount tool which exposes the smallest sane subset of mount options might be useful to some - and could also be added to cifs-utils On Thu, Jun 28, 2018 at 10:44 PM Kenneth Dsouza <kdsouza@xxxxxxxxxx> wrote: > > Thanks, I will take a look at the pre-existing code for > reference(nfs-utils and other). > > On Fri, Jun 29, 2018 at 8:12 AM, Steve French <smfrench@xxxxxxxxx> wrote: > > I think this is a reasonable idea - and nfs-utils's parsing for this > > config file (in mount.nfs e.g.) may be similar enough to smb3 > > requirements in some cases - but don't rule out the idea of seeing if > > anything is shareable/reuseable with Samba (to allow e.g. smbcacls or > > small client utilities to benefit from cifs.ko configuration and vice > > versa). In addition don't rule out the idea of writing small > > cifs-utils that allow sane setting of the text configuration file (ala > > "net conf <section> <keyword> <value>" or equivalent. One of the > > curses of many text config files is difficulty figuring out > > options/syntax etc. and making spelling mistakes so in a perfect world > > the user could set the config file values with an easy to use > > cifs-util tool (vaguely similar to "net conf ..." perhaps) > > > > If we allow setting the 5-10 module install parms and then the things > > configurable in /proc/fs/cifs/* ... we would need some way to load > > them on reboot. > > > > The nfs example may be useful but it is more focused on mount parms it > > seems rather than other config values. > > > > But if you want to pursue this it seems promising to investigate > > nfsmount.conf and whether there is something vaguely similar we could > > do for smb3 but ... I would prefer if along with that we had an easy > > to use tool to set the values and provide help on the valid options > > etc. (there may be a lot we can also learn by the way from other fs > > tools as models - e.g. "iostat" and "nfsiostat" if looking at these > > tools for other file systems) > > On Thu, Jun 28, 2018 at 9:35 PM Kenneth Dsouza <kdsouza@xxxxxxxxxx> wrote: > >> > > I agree we can have a cifs-conf command for example. This command > will help us retrieve mount settings and make changes directly to the > /etc/cifsmount.conf. > This will help us to only add valid options and avoid typos. > > >> > >> I was just wondering why we don't have a /etc/cifsmount.conf just like /etc/nfsmount.conf for mount options. I would like to work on it, if we can add this functionality. > >> Using this we can easily disable smb1. > >> > >> Regards, > >> Kenneth D'souza > > > > > > > > -- > > Thanks, > > > > Steve -- Thanks, Steve -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
