ken-ji Posted March 27, 2015 Share Posted March 27, 2015 Hi guys, Setting up my first unRaid box to replace my Slackware NAS (after I destroyed my data with an (unknowingly) aborted MD resize operation ) I'm using 6b14 with Pro license. However, I can't make sense of the NFS export option for user shares... Both Public and Secure give me: root@MediaStore:~# exportfs -v /mnt/user/Media <world>(rw,async,wdelay,insecure,root_squash,all_squash,no_subtree_check,fsid=100,anonuid=99,anongid=100,sec=sys,rw,root_squash,all_squash) root@MediaStore:~# exportfs -v /mnt/user/Media <world>(ro,async,wdelay,insecure,root_squash,all_squash,no_subtree_check,fsid=100,anonuid=99,anongid=100,sec=sys,ro,root_squash,all_squash) While private with 192.168.2.2(rw) gives me: root@MediaStore:~# exportfs -v /mnt/user/Media 192.168.2.2(ro,async,wdelay,insecure,root_squash,all_squash,no_subtree_check,fsid=100,anonuid=99,anongid=100,sec=sys,ro,root_squash,all_squash) So does this mean to have writable NFS shares, they can only be public? while secure is read-only and private is read-only to specific machines/networks? 1 Quote Link to comment
segator Posted March 28, 2015 Share Posted March 28, 2015 I have same problem You know something new? Quote Link to comment
Ice_Black Posted June 25, 2015 Share Posted June 25, 2015 Same problem in unraid 6.0 final Quote Link to comment
limetech Posted June 25, 2015 Share Posted June 25, 2015 I'm assuming for 'Rule' on NFS share settings for Private share you set to "192.168.2.2(rw)" right? If I look at /etc/exports it appears correct, yet output ouf 'exportfs -v' does indeed show (ro). Never noticed this before - is there something wrong inside /etc/exports (asking you guys who might know this before I go research what's happening)? Quote Link to comment
ken-ji Posted June 26, 2015 Author Share Posted June 26, 2015 I think I solved it. I absolutely needed to add (sec=sys) For a NFS share called Test rule: empty /etc/exports: "/mnt/user/Test" -async,no_subtree_check,fsid=110 exportfs: exportfs: No host name given with /mnt/user/Test (ro,async,wdelay,hide,nocrossmnt,secure,root_squash,no_all_squash,no_subtree_check,secure_locks,acl,fsid=110,anonuid=65534,anongid=65534,sec=sys,ro,root_squash,no_all_squash), suggest *(ro,async,wdelay,hide,nocrossmnt,secure,root_squash,no_all_squash,no_subtree_check,secure_locks,acl,fsid=110,anonuid=65534,anongid=65534,sec=sys,ro,root_squash,no_all_squash) to avoid warning /mnt/user/Test <world>(ro,async,wdelay,root_squash,no_subtree_check,fsid=110,sec=sys,ro,root_squash,no_all_squash) With a rule like: rule: 192.168.2.0/24(rw) /etc/exports: "/mnt/user/Test" -async,no_subtree_check,fsid=110 192.168.2.0/24(rw) exportfs: /mnt/user/Test 192.168.2.0/24(ro,async,wdelay,root_squash,no_subtree_check,fsid=110,sec=sys,ro,root_squash,no_all_squash) /mnt/disk1 <world>(ro,async,wdelay,insecure,root_squash,all_squash,no_subtree_check,fsid=11,anonuid=99,anongid=100,sec=sys,ro,root_squash,all_squash) the rw does not take effect unless I add sec=sys Rule: 192.168.2.4(sec=sys,rw) /etc/exports: "/mnt/user/Test" -async,no_subtree_check,fsid=110 192.168.2.0/24(sec=sys,rw) exportfs: /mnt/user/Test 192.168.2.0/24(rw,async,wdelay,root_squash,no_subtree_check,fsid=110,sec=sys,rw,root_squash,no_all_squash) /mnt/disk1 <world>(ro,async,wdelay,insecure,root_squash,all_squash,no_subtree_check,fsid=11,anonuid=99,anongid=100,sec=sys,ro,root_squash,all_squash) Hope this helps 1 2 Quote Link to comment
ken-ji Posted June 26, 2015 Author Share Posted June 26, 2015 Additionally from: http://linux.die.net/man/5/exports RPCSEC_GSS security You may use the special strings "gss/krb5", "gss/krb5i", or "gss/krb5p" to restrict access to clients using rpcsec_gss security. However, this syntax is deprecated; on linux kernels since 2.6.23, you should instead use the "sec=" export option:sec= The sec= option, followed by a colon-delimited list of security flavors, restricts the export to clients using those flavors. Available security flavors include sys (the default--no cryptographic security), krb5 (authentication only), krb5i (integrity protection), and krb5p (privacy protection). For the purposes of security flavor negotiation, order counts: preferred flavors should be listed first. The order of the sec= option with respect to the other options does not matter, unless you want some options to be enforced differently depending on flavor. In that case you may include multiple sec= options, and following options will be enforced only for access using flavors listed in the immediately preceding sec= option. The only options that are permitted to vary in this way are ro, rw, no_root_squash, root_squash, and all_squash. Quote Link to comment
dereitz Posted November 18, 2021 Share Posted November 18, 2021 I just wanted to say 'Thank you!' for sharing your experience! It was a big help! The unRaid documentation in this area is seriously lacking... Quote Link to comment
yoleska Posted June 20, 2023 Share Posted June 20, 2023 Ditto, found this very helpful. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.