"zfs set" write a wrong entry in "etc/zfs/exports" when the command contains a "-" character in the hostname. Fix: Complement the "-" character manually into the "etc/zfs/exports" file. -------------------------------------------------------------------- root@XXX ~ # cat /etc/zfs/exports # !!! DO NOT EDIT THIS FILE MANUALLY !!! /nfs -maproot=root xxxxxx-01 -------------------------------------------------------------------- -------------------------------------------------------------------- root@XXX ~ # service mountd reload -------------------------------------------------------------------- -------------------------------------------------------------------- root@XXX ~ # showmount -e Exports list on localhost: /nfs xxxxxx-01 -------------------------------------------------------------------- How-To-Repeat: -------------------------------------------------------------------- root@XXX ~ # zfs set sharenfs="-maproot=root xxxxxx-01" tank/nfs -------------------------------------------------------------------- -------------------------------------------------------------------- root@XXX ~ # cat /etc/zfs/exports # !!! DO NOT EDIT THIS FILE MANUALLY !!! /nfs -maproot=root xxxxxx 01 -------------------------------------------------------------------- -------------------------------------------------------------------- root@XXX ~ # showmount -e Exports list on localhost: --------------------------------------------------------------------
Still occurs on 10_RELEASE
Any new information? It's almost 3 years now :)
Created attachment 167756 [details] Patch cddl/compat/opensolaris/misc/fsshare.c for saner options parsing Please use the attached patch. -- Martin
Duplicate of bug #168158?
May I suggest that my patch be committed and then this issue closed? -- Martin
(In reply to Martin Birgmeier from comment #5) Is there a case my (smaller) patch doesn't handle? https://bz-attachments.freebsd.org/attachment.cgi?id=158168 (Attached to bug #168158)
It's been a while... if I remember correctly I wanted to preserve options not in the list of known options but already starting with a dash. -- Martin
(In reply to Martin Birgmeier from comment #7) The current behavior strips leading dashes from un-recognized options. Input = -foo -ro mapall test_host test-host current output = foo -ro -mapall test_host test host w/patch in bug #168158 = foo -ro -mapall test_host test-host w/patch in bug #176449 = -foo -ro -mapall test_host test-host So the other patch is minimal change (only fixes preserving dashes inside host names) while the patch here also passes unrecognized options with leading dashes. Not sure which is preferred in this case; stripping the dash is likely not optimal from a security point of view, as -foo becomes the hostname foo... Should it perhaps remove strings that look like options but aren't recognized? Or pass them as (invalid) arguments into exports?
batch change: For bugs that match the following - Status Is In progress AND - Untouched since 2018-01-01. AND - Affects Base System OR Documentation DO: Reset to open status. Note: I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.