NFS Share: RO to network, but RW to nodes

[ThyWhiteHawk]

Hi,

I'm attempting to migrate my Linux file server over to FreeNAS. The nodes on the network use NFS to mount all shares - well, the whole house runs Linux (and soon FreeNAS of course), so why choose anything else ;-)

Anyway, I'm struggling to export a share to the entire network RO, but at the same time to particular nodes as RW, as I have set up on my Linux box. I've been Googling for a while, but the only thing I've found is an unsolved post in this forum:
( https://forums.freenas.org/index.php?threads/share-nfs-rw-to-one-host-but-ro-to-all-others.50883/ )

The reason that I want to share this to the entire network is so that any of the media players, or indeed any device can access it, without me having to explicitly list an IP address.

My Linux box's /etc/exports looks like this (only relevant lines shown)

Code:

# Generic read-only access for everyone on network
/export/music		192.168.1.0/24(ro,nohide,insecure,no_subtree_check,async)

# Specific write access for picard
/export/music		picard(rw,nohide,insecure,no_subtree_check,async)

In the FreeNAS GUI, I set up the RO share, and the resultant /etc/exports looks like:

Code:

/mnt/storage/music  -ro -network 192.168.1.0/24

However, when I attempt to set up RW access for "picard", the web GUI reports:

Code:

The network 0.0.0.0/24 is already being shared and cannot be used twice for the same filesystem

Or, if I also specify the network:

Code:

The network 192.168.1.0/24 is already being shared and cannot be used twice for the same filesystem

Any solution?

Thanks,
Gavin.

 

[Nick2253]

Does Picard have a static IP? If not, I would change that, and create the share specifically for that IP.

 

[ThyWhiteHawk]

All nodes (apart from servers) have dynamically allocated static IPs (I run DNSMasq to do this), so yes it does. All servers are static.

It appears to me that the GUI simply doesn't allow this, yet it is perfectly valid in /etc/exports to have multiple entries for the same share (as I already have my Linux box configured this way). NFS effectively allows /etc/exports entries to be overridden by other entries - the GUI does not.

I' like each node to be able to access exactly the same dataset on the same volume, but with either RO or RW permissions depending on the node. Obviously, each share that I've set up has specific UID and GIDs... so I can partially control write access.

One (slightly paranoid) reason for my desired (and currently operational) solution is: there are several Kodi media players in the house - Raspberry Pis, phones, tablets and PCs. They all access the media via NFS (the only way to see a list of available media from Kore ( http://kodi.wiki/view/Kore ) is if the filesystem is mounted - UPnP / DLNA don't allow you to browse and select media on other machines). I only want certain users on certain nodes to be able to write to the media directories (e.g. the music share)... what if the kids installed some dodgy Kodi add-on?!

 

[ThyWhiteHawk]

I've just tried creating a RW share of "music" for picard, and then creating a RO share of "music" for specific nodes, and that still complains about:
The network 0.0.0.0/0 is already being shared and cannot be used twice for the same filesystem

Doing more Googling, it appears that any manual modifications to /etc/exports will be overwritten at reboot.

Am I just going to have to give RW permissions to the whole network and take my paranoid hat off? :-(

 

[jgreco]

Try creating a second NFS share for the same mountpoint. It works, or at least it has in the past.

/mnt/poolname/sharename -maproot=root:wheel 10.2.3.4
/mnt/poolname/sharename -ro -maproot=root:wheel -network 10.5.6.0/24
/mnt/poolname/sharename -ro -maproot=root:wheel -network 10.7.8.0/24

Some names and addresses have been changed to protect the innocent. However, FreeNAS had no problem generating that config by creating two shares.

 

[Nick2253]

Have you confirmed that your FreeNAS server has your network's DNS server set up, and is able to resolve "picard"?

 

[ThyWhiteHawk]

Try creating a second NFS share for the same mountpoint. It works, or at least it has in the past.

/mnt/poolname/sharename -maproot=root:wheel 10.2.3.4
/mnt/poolname/sharename -ro -maproot=root:wheel -network 10.5.6.0/24
/mnt/poolname/sharename -ro -maproot=root:wheel -network 10.7.8.0/24

That's exactly what I'm attempting to do via the web GUI... but "computer says no" ... even for different networks as you have. Can I assume that you manually edited the /etc/exports file for this? Is it preserved after a reboot?

 

[ThyWhiteHawk]

Have you confirmed that your FreeNAS server has your network's DNS server set up, and is able to resolve "picard"?

Yes, DNS (and default gateway) are set up, so there is no problems in resolving names.

 

[jgreco]

That's exactly what I'm attempting to do via the web GUI... but "computer says no" ... even for different networks as you have. Can I assume that you manually edited the /etc/exports file for this? Is it preserved after a reboot?

No, you can't assume that I manually edited the /etc/exports file for that, and of course it's preserved, because it's generated from the FreeNAS conf database. As I said,

It works, or at least it has in the past. [...] However, FreeNAS had no problem generating that config by creating two shares.

Whether or not some overly helpful GUI coder broke this functionality is a question I haven't researched, though, so there's certainly a possibility it no longer works. Obviously this *should* work for all the obvious reasons, so if it doesn't, I definitely suggest you open a bug report and post the number here. One way or another it'll get sorted out.

 

[ThyWhiteHawk]

because it's generated from the FreeNAS conf database.

I meant is manually editing it preserved - which would put it out of sync with the database, and presumably FreeNAS would re-write it based upon the database?

Whether or not some overly helpful GUI coder broke this functionality is a question I haven't researched, though, so there's certainly a possibility it no longer works. Obviously this *should* work for all the obvious reasons, so if it doesn't, I definitely suggest you open a bug report and post the number here. One way or another it'll get sorted out.

Thanks. That's what I thought! Can I ask which version you run? I'll perhaps install that one in a VM on my desktop (I already have a FreeNAS VM that I was playing with until my new hardware arrived) and investigate. I downloaded the latest: v11.1 yesterday for my real system. If the two systems differ in behaviour, I'll raise a bug report.

 

[jgreco]

Well the database entry backing it up dates all the way back to 8.*, I'm not going to mess with it now because it's a production server and I don't need it breaking.

If I wasn't already stressing the systems here with eight parallel builds of three major revs of FreeBSD (sigh, preparing for the inevitable Meltdown/Spectre VM rebuilding debacle) I would probably go and give a few revs of FreeNAS a try to see if I could identify this for you, but, sorry, you're out of luck. Blame Intel though, not me, please!

 

[ThyWhiteHawk]

If I wasn't already stressing the systems here with eight parallel builds of three major revs of FreeBSD (sigh, preparing for the inevitable Meltdown/Spectre VM rebuilding debacle) I would probably go and give a few revs of FreeNAS a try to see if I could identify this for you, but, sorry, you're out of luck. Blame Intel though, not me, please!

Well, I've just tested v9.10 (I just happened to have that from a time that I was playing a while ago)... and it works exactly as I'd expect it to, first time, no hassle (see image)!

I'll get a bug report raised

 

[ThyWhiteHawk]

Bug #27667 created.

 

[jgreco]

Yeah, well, sorry for the trouble. There are some excellent coders working the UI of FreeNAS, but this is not the first time I've seen them "helpfully" restrict something like this because they didn't understand the use case or why it should be perfectly valid. I'm guessing it will be fixed quickly enough,

 

[ThyWhiteHawk]

I'm guessing it will be fixed quickly enough,

I hope so... but at the end of the day, until it's fixed, I'll just allow the entire network RW access, since I am in control of my network after all

 

[jgreco]

Well, if nothing else, it is a good opportunity to contemplate your use of user ID's and permissions on the share. There's nothing bad about belt-and-suspenders, so making sure maproot is off and setting the writer uid to a UID that doesn't exist on any of the client boxes gets you some protection.