Superb quality and spec AB-Com PULSe 4K SE. Crazy offer! Only £99! FREE UK DELIVERY! 4K UHD, Enigma 2, Multiboot 4 images & more!...
Superb quality and spec AB-Com PULSe 4K Rev II Twin Satellite tuner only £149! FREE UK DELIVERY! 4K UHD, Enigma 2, SATA HDD facility, Multiboot 4 images & more!...

[ViX_Misc] Will my change to NFS survive an upgrade?

smipx

Forum Supporter
Donated Member
Joined
Nov 30, 2019
Messages
475
Reaction score
9
Points
18
What type of support thread are you creating?
Support question
What OpenViX Image build number are you using?
6.9.002
Have you tried re-flashing WITHOUT settings restore?
NO
Have you tried re-flashing WITH a settings restore?
NO
Hi all,

I changed broadband provider today and have a plusnet hub 2 / BT smart hub 2. As soon as i switched over my boxes to the new hub I noticed that an NFS share on my "slave" box stopped working. It could no longer see any NFS shares on my "Master" box. After much wrangling and googling I came across the solution which has fixed the issue.

On the slave box (where the mount point created) I had to change the parameters of the share from "rw,sync,no_subtree_check" to "rw,sync,no_subtree_check,insecure"
additionally
On the master box where the actual share is I had to manually edit the "exports" file under /etc/ and change each entry from "rw,no_root_squash,async,no_subtree_check" to "rw,no_root_squash,async,no_subtree_check,insecure"

Two questions:

1. As I don't allow connections to my boxes from outside the LAN I assume the changes are safe enough

2. I'm assuming he change I made in the Mount Points menu on the slave will be captured by a backup and restored as the need arises (upgrades / reinstalls) but I suspect the change on the master box to the "exports" file under /etc/ will not be backed up and so I will have to make this change every time I upgrade. Hopefully not but I wanted to check.

Thanks
Paul
 
One thing with using client mode recheck ip of box has not changed by one digit .
Sometimes things change and wonder why it stopped?
I dont think i had to mess around with files.
 
On the slave box (where the mount point created) I had to change the parameters of the share from "rw,sync,no_subtree_check" to "rw,sync,no_subtree_check,insecure"
sync will slow things down.
It will increase reliability, but if the link isn't reliable then you sh/wouldn't be using it for recordings anyway.
 
Hi all,

I changed broadband provider today and have a plusnet hub 2 / BT smart hub 2. As soon as i switched over my boxes to the new hub I noticed that an NFS share on my "slave" box stopped working. It could no longer see any NFS shares on my "Master" box. After much wrangling and googling I came across the solution which has fixed the issue.

On the slave box (where the mount point created) I had to change the parameters of the share from "rw,sync,no_subtree_check" to "rw,sync,no_subtree_check,insecure"
additionally
On the master box where the actual share is I had to manually edit the "exports" file under /etc/ and change each entry from "rw,no_root_squash,async,no_subtree_check" to "rw,no_root_squash,async,no_subtree_check,insecure"

Two questions:

1. As I don't allow connections to my boxes from outside the LAN I assume the changes are safe enough

2. I'm assuming he change I made in the Mount Points menu on the slave will be captured by a backup and restored as the need arises (upgrades / reinstalls) but I suspect the change on the master box to the "exports" file under /etc/ will not be backed up and so I will have to make this change every time I upgrade. Hopefully not but I wanted to check.

Thanks
Paul
You can add it into your backup settings - just go diwn directory/ filelist and tick it
 
sync will slow things down.
It will increase reliability, but if the link isn't reliable then you sh/wouldn't be using it for recordings anyway.
Thanks for that. The sync is part of the default setup of the share and not something I added so should that be removed from the default setup of a mount point? I only added the insecure parameter.
 
Thanks for that. The sync is part of the default setup of the share and not something I added so should that be removed from the default setup of a mount point? I only added the insecure parameter.
If you're not having any problems then don't change it. Just something to be aware of if you do run into issues with disk writing.
 
If you're not having any problems then don't change it. Just something to be aware of if you do run into issues with disk writing.
OK thanks. Maybe I'll try async one day. Does it make a lot of difference in the real world of openvix and browsing the NFS share for recordings and playing them?
 
Actually I made an error. On the slave box inside mount manager I actually set: rw,nolock,tcp,noresvport and not what I typo'd earlier
On the master box the settings inside the exports file are (now):

/media/hdd/ 192.168.0.0/255.255.0.0(rw,no_root_squash,sync,no_subtree_check,insecure)
/media/hdd2/ 192.168.0.0/255.255.0.0(rw,no_root_squash,sync,no_subtree_check,insecure)
/media/usb/ 192.168.0.0/255.255.0.0(rw,no_root_squash,sync,no_subtree_check,insecure)

I did not change any of the other options apart from adding the "insecure". Do you think it is worth changing sync to async. Reason I ask is that is the default (sync) and I am wondering why if it is only a TV recording box. Would async not be better? I am assuming that async is a lot quicker.

Cheers,
Paul
 
Would async not be better? I am assuming that async is a lot quicker.
It will make no difference for reading.
For writing it might make a difference, but that happens asynchronously on the Linux side anyway (in that you write into a buffer and the kernel flushes it sometime later - its that flush which is synchronous to the NFS server).
 
As an afterthought using sync shouldn't actually be an issue.
A recording (and multiple ones) will run at a roughly constant rate and the OS buffering of the writes will mean that you could probably handle a delay of over a minute in write acknowledgement (which would in itself indicate a problem somewhere) without issue.
 

OpenViX Feeds Status

Back
Top