nfs-utils commit 11ba3b1e01b67b7d19f26fba94fabdb60878e809 has exacerbated the effects of a bug around sec= option specification, or possibly around default option ordering (depending on how you look at it). Default options in /etc/exportfs, e.g. "-foo,bar" are, as I understand it, supposed to be overrideable by per-machine options, e.g., this works: /foo -ro one.machine two.machine(rw) three.machine This should be equivalent to /foo one.machine(ro) two.machine(rw) three.machine(ro) (or, at least, there is no other way of doing this that I can see, without massively repeating mount options, which is the old plague which default options are supposed to fix). Unfortunately, this is not true for the sec= option, because specifying sec= forces the implicit addition of a bunch of other options courtesy of secinfo_show(), which is used when populating /var/lib/nfs/etab. Unfortunately, Chuck's commit, by implicitly specifying sec= if not already present, turned this from a nearly-invisible bug that only affected people who used sec= in the default option string to a bug that affects everyone who uses default options to specify read-writeness for some mounts rather than others, and quite possibly breaks read-write mounts and other things for everyone who uses per-machine mount options at all. e.g., for me, this line in /etc/exportfs: /usr/src -fsid=16,no_root_squash,no_subtree_check,async mutilate(rw) produced this line in etab /usr/src mutilate.wkstn.nix(rw,async,wdelay,hide,nocrossmnt,secure,no_root_squash,no_all_squash,no_subtree_check,secure_locks,acl,fsid=16,anonuid=65534,anongid=65534) before that patch, and /usr/src mutilate.wkstn.nix(rw,async,wdelay,hide,nocrossmnt,secure,no_root_squash,no_all_squash,no_subtree_check,secure_locks,acl,fsid=16,anonuid=65534,anongid=65534,sec=sys,ro,no_root_squash,no_all_squash) afterwards. Reverting 11ba3b1e fixes it, but clearly it is not the culprit itself, because you can reproduce it in an nfs-utils with this patch reverted by just adding 'sec=sys' after 'async' in the exportfs line above: the bug is deeper. I *think* -- but am not confident enough to try to fix it -- that the actual bug is that the options are being emitted in the wrong order: since later options supercede earlier ones, the per-machine options should be emitted last, rather than first, as at present. I think. Probably. Maybe. I could be wrong, but this is clearly a behaviour change and it breaks my setup :) -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
