Debian NFS wait too long when the other Debian is turned off
Clash Royale CLAN TAG#URR8PPP
up vote
0
down vote
favorite
I have a home network with two Debian 9 PCs. I'm using NFS to share a folder from each PC with the other, both read-only. The config files are:
/etc/exports on Machine1:
/path/on/machine1/share machine.2.ip(ro,sync,no_subtree_check)
/etc/fstab on Machine1:
machine.2.ip:/path/on/machine2/share /path/on/machine1/machine2-share nfs
When both computers are on, it works fine. However, when one computer is off, the other take two minutes waiting to find the other PC, so it can mount the shared directory. I would like to reduce this time to something more practical, like 5 seconds. I haven't found anything in the manual. How can I do that?
debian nfs delay
asked Aug 31 at 15:57
Rodrigo
1851217
add a comment |Â
up vote
0
down vote
favorite
I have a home network with two Debian 9 PCs. I'm using NFS to share a folder from each PC with the other, both read-only. The config files are:
/etc/exports on Machine1:
/path/on/machine1/share machine.2.ip(ro,sync,no_subtree_check)
/etc/fstab on Machine1:
machine.2.ip:/path/on/machine2/share /path/on/machine1/machine2-share nfs
When both computers are on, it works fine. However, when one computer is off, the other take two minutes waiting to find the other PC, so it can mount the shared directory. I would like to reduce this time to something more practical, like 5 seconds. I haven't found anything in the manual. How can I do that?
debian nfs delay
asked Aug 31 at 15:57
Rodrigo
1851217
add a comment |Â
up vote
0
down vote
favorite
up vote
0
down vote
favorite
I have a home network with two Debian 9 PCs. I'm using NFS to share a folder from each PC with the other, both read-only. The config files are:
/etc/exports on Machine1:
/path/on/machine1/share machine.2.ip(ro,sync,no_subtree_check)
/etc/fstab on Machine1:
machine.2.ip:/path/on/machine2/share /path/on/machine1/machine2-share nfs
When both computers are on, it works fine. However, when one computer is off, the other take two minutes waiting to find the other PC, so it can mount the shared directory. I would like to reduce this time to something more practical, like 5 seconds. I haven't found anything in the manual. How can I do that?
debian nfs delay
asked Aug 31 at 15:57
Rodrigo
1851217
I have a home network with two Debian 9 PCs. I'm using NFS to share a folder from each PC with the other, both read-only. The config files are:
/etc/exports on Machine1:
/path/on/machine1/share machine.2.ip(ro,sync,no_subtree_check)
/etc/fstab on Machine1:
machine.2.ip:/path/on/machine2/share /path/on/machine1/machine2-share nfs
When both computers are on, it works fine. However, when one computer is off, the other take two minutes waiting to find the other PC, so it can mount the shared directory. I would like to reduce this time to something more practical, like 5 seconds. I haven't found anything in the manual. How can I do that?
debian nfs delay
debian nfs delay
asked Aug 31 at 15:57
Rodrigo
1851217
asked Aug 31 at 15:57
Rodrigo
1851217
asked Aug 31 at 15:57
Rodrigo
1851217
asked Aug 31 at 15:57
Rodrigo
1851217
asked Aug 31 at 15:57
Rodrigo
1851217
1851217
add a comment |Â
add a comment |Â
2 Answers
2
active
oldest
votes
up vote
4
down vote
If automounting isn’t appropriate, you can use x-systemd.mount-timeout= to specify a shorter timeout:
machine.2.ip:/path/on/machine2/share /path/on/machine1/machine2-share nfs x-systemd.mount-timeout=5
The bg NFS mount option might be useful: it forks a mount which retries in the background. systemd understands this option and configures the mount appropriately.
answered Aug 31 at 17:25
Stephen Kitt
147k22321388
This works when I turn my machine on with the other turned off. But if both are on and then the other goes off (i.e. the share is already mounted), then Nautilus, a Firefox "send file" window, and even a singlelsget frozen.
– Rodrigo
Sep 11 at 13:14
@Rodrigo yes, that’s a feature of NFS and there isn’t much that can be done about it other than ensuring the shared volume is unmounted before the machine serving it is switched off. But you didn’t mention that requirement in your question :-/.
– Stephen Kitt
Sep 11 at 13:18
1
@Rodrigo the question doesn’t mention that this is on a home network where machines are liable to be switched off with little warning. The question is about NFS mounts taking too long when the exporting machine is off; that has been addressed. If you have another question about dealing with mounted NFS volumes “going awayâ€Â, I suggest you ask a new question. A similar question exists already but it doesn’t have a satisfying answer IMO.
– Stephen Kitt
Sep 12 at 8:04
Is there a home network where machines are never turned off? Yes, it seems I need to ask a new question, since in your country the energy seems to be "free". Tip: it's never free.
– Rodrigo
Sep 12 at 12:45
@Rodrigo I’m not arguing about the energy part, I’m just saying that you’re changing the question. You could edit your question to turn it into “Please help me fix all the issues I have running NFS on a home networkâ€Â, but that would be unfair to the authors of the existing answers. You asked a question, got answers, one of which was good enough for you to accept it; then you came up with another question, and decided to re-use your existing one. That doesn’t work too well with the Q&A format of StackExchange (but I imagine you know that given your SO experience).
– Stephen Kitt
Sep 12 at 12:48
 |Â
show 1 more comment
up vote
2
down vote
Perhaps consider using systemd automount?
I am using it and am happy with the way it works:
<ip-address>:/home/export/nfs /home/share/nfs nfs x-systemd.automount,noauto,_netdev 0 0
With this setup, the NFS share is not mounted at boot time, but automounts when you try to access the share (/home/share/nfs) in this trivial example.
answered Aug 31 at 16:23
maulinglawns
6,11621225
Thank you. Do I necessarily need thenoautoand_netdevoptions as well? From the manual it isn't clear to me.
– Rodrigo
Sep 1 at 1:26
@Rodrigo This was just an example, you can try to run without those options.
– maulinglawns
Sep 1 at 5:01
Yes, I'll try later. Thanks again!
– Rodrigo
Sep 1 at 8:10
I was too fast accepting your answer. When the other PC went off, Nautilus won't respond ever. Not even save as windows work. I had to use the other answer to make it work.
– Rodrigo
Sep 2 at 6:55
@Rodrigo Yes, thex-systemd.mount-timeoutoption can be useful as well.
– maulinglawns
Sep 2 at 7:13
 |Â
show 1 more comment
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
4
down vote
If automounting isn’t appropriate, you can use x-systemd.mount-timeout= to specify a shorter timeout:
machine.2.ip:/path/on/machine2/share /path/on/machine1/machine2-share nfs x-systemd.mount-timeout=5
The bg NFS mount option might be useful: it forks a mount which retries in the background. systemd understands this option and configures the mount appropriately.
answered Aug 31 at 17:25
Stephen Kitt
147k22321388
This works when I turn my machine on with the other turned off. But if both are on and then the other goes off (i.e. the share is already mounted), then Nautilus, a Firefox "send file" window, and even a singlelsget frozen.
– Rodrigo
Sep 11 at 13:14
@Rodrigo yes, that’s a feature of NFS and there isn’t much that can be done about it other than ensuring the shared volume is unmounted before the machine serving it is switched off. But you didn’t mention that requirement in your question :-/.
– Stephen Kitt
Sep 11 at 13:18
1
@Rodrigo the question doesn’t mention that this is on a home network where machines are liable to be switched off with little warning. The question is about NFS mounts taking too long when the exporting machine is off; that has been addressed. If you have another question about dealing with mounted NFS volumes “going awayâ€Â, I suggest you ask a new question. A similar question exists already but it doesn’t have a satisfying answer IMO.
– Stephen Kitt
Sep 12 at 8:04
Is there a home network where machines are never turned off? Yes, it seems I need to ask a new question, since in your country the energy seems to be "free". Tip: it's never free.
– Rodrigo
Sep 12 at 12:45
@Rodrigo I’m not arguing about the energy part, I’m just saying that you’re changing the question. You could edit your question to turn it into “Please help me fix all the issues I have running NFS on a home networkâ€Â, but that would be unfair to the authors of the existing answers. You asked a question, got answers, one of which was good enough for you to accept it; then you came up with another question, and decided to re-use your existing one. That doesn’t work too well with the Q&A format of StackExchange (but I imagine you know that given your SO experience).
– Stephen Kitt
Sep 12 at 12:48
 |Â
show 1 more comment
up vote
4
down vote
If automounting isn’t appropriate, you can use x-systemd.mount-timeout= to specify a shorter timeout:
machine.2.ip:/path/on/machine2/share /path/on/machine1/machine2-share nfs x-systemd.mount-timeout=5
The bg NFS mount option might be useful: it forks a mount which retries in the background. systemd understands this option and configures the mount appropriately.
answered Aug 31 at 17:25
Stephen Kitt
147k22321388
This works when I turn my machine on with the other turned off. But if both are on and then the other goes off (i.e. the share is already mounted), then Nautilus, a Firefox "send file" window, and even a singlelsget frozen.
– Rodrigo
Sep 11 at 13:14
@Rodrigo yes, that’s a feature of NFS and there isn’t much that can be done about it other than ensuring the shared volume is unmounted before the machine serving it is switched off. But you didn’t mention that requirement in your question :-/.
– Stephen Kitt
Sep 11 at 13:18
1
@Rodrigo the question doesn’t mention that this is on a home network where machines are liable to be switched off with little warning. The question is about NFS mounts taking too long when the exporting machine is off; that has been addressed. If you have another question about dealing with mounted NFS volumes “going awayâ€Â, I suggest you ask a new question. A similar question exists already but it doesn’t have a satisfying answer IMO.
– Stephen Kitt
Sep 12 at 8:04
Is there a home network where machines are never turned off? Yes, it seems I need to ask a new question, since in your country the energy seems to be "free". Tip: it's never free.
– Rodrigo
Sep 12 at 12:45
@Rodrigo I’m not arguing about the energy part, I’m just saying that you’re changing the question. You could edit your question to turn it into “Please help me fix all the issues I have running NFS on a home networkâ€Â, but that would be unfair to the authors of the existing answers. You asked a question, got answers, one of which was good enough for you to accept it; then you came up with another question, and decided to re-use your existing one. That doesn’t work too well with the Q&A format of StackExchange (but I imagine you know that given your SO experience).
– Stephen Kitt
Sep 12 at 12:48
 |Â
show 1 more comment
up vote
4
down vote
up vote
4
down vote
If automounting isn’t appropriate, you can use x-systemd.mount-timeout= to specify a shorter timeout:
machine.2.ip:/path/on/machine2/share /path/on/machine1/machine2-share nfs x-systemd.mount-timeout=5
The bg NFS mount option might be useful: it forks a mount which retries in the background. systemd understands this option and configures the mount appropriately.
answered Aug 31 at 17:25
Stephen Kitt
147k22321388
If automounting isn’t appropriate, you can use x-systemd.mount-timeout= to specify a shorter timeout:
machine.2.ip:/path/on/machine2/share /path/on/machine1/machine2-share nfs x-systemd.mount-timeout=5
The bg NFS mount option might be useful: it forks a mount which retries in the background. systemd understands this option and configures the mount appropriately.
answered Aug 31 at 17:25
Stephen Kitt
147k22321388
answered Aug 31 at 17:25
Stephen Kitt
147k22321388
answered Aug 31 at 17:25
Stephen Kitt
147k22321388
answered Aug 31 at 17:25
Stephen Kitt
147k22321388
147k22321388
This works when I turn my machine on with the other turned off. But if both are on and then the other goes off (i.e. the share is already mounted), then Nautilus, a Firefox "send file" window, and even a singlelsget frozen.
– Rodrigo
Sep 11 at 13:14
@Rodrigo yes, that’s a feature of NFS and there isn’t much that can be done about it other than ensuring the shared volume is unmounted before the machine serving it is switched off. But you didn’t mention that requirement in your question :-/.
– Stephen Kitt
Sep 11 at 13:18
1
@Rodrigo the question doesn’t mention that this is on a home network where machines are liable to be switched off with little warning. The question is about NFS mounts taking too long when the exporting machine is off; that has been addressed. If you have another question about dealing with mounted NFS volumes “going awayâ€Â, I suggest you ask a new question. A similar question exists already but it doesn’t have a satisfying answer IMO.
– Stephen Kitt
Sep 12 at 8:04
Is there a home network where machines are never turned off? Yes, it seems I need to ask a new question, since in your country the energy seems to be "free". Tip: it's never free.
– Rodrigo
Sep 12 at 12:45
@Rodrigo I’m not arguing about the energy part, I’m just saying that you’re changing the question. You could edit your question to turn it into “Please help me fix all the issues I have running NFS on a home networkâ€Â, but that would be unfair to the authors of the existing answers. You asked a question, got answers, one of which was good enough for you to accept it; then you came up with another question, and decided to re-use your existing one. That doesn’t work too well with the Q&A format of StackExchange (but I imagine you know that given your SO experience).
– Stephen Kitt
Sep 12 at 12:48
 |Â
show 1 more comment
This works when I turn my machine on with the other turned off. But if both are on and then the other goes off (i.e. the share is already mounted), then Nautilus, a Firefox "send file" window, and even a singlelsget frozen.
– Rodrigo
Sep 11 at 13:14
@Rodrigo yes, that’s a feature of NFS and there isn’t much that can be done about it other than ensuring the shared volume is unmounted before the machine serving it is switched off. But you didn’t mention that requirement in your question :-/.
– Stephen Kitt
Sep 11 at 13:18
1
@Rodrigo the question doesn’t mention that this is on a home network where machines are liable to be switched off with little warning. The question is about NFS mounts taking too long when the exporting machine is off; that has been addressed. If you have another question about dealing with mounted NFS volumes “going awayâ€Â, I suggest you ask a new question. A similar question exists already but it doesn’t have a satisfying answer IMO.
– Stephen Kitt
Sep 12 at 8:04
Is there a home network where machines are never turned off? Yes, it seems I need to ask a new question, since in your country the energy seems to be "free". Tip: it's never free.
– Rodrigo
Sep 12 at 12:45
@Rodrigo I’m not arguing about the energy part, I’m just saying that you’re changing the question. You could edit your question to turn it into “Please help me fix all the issues I have running NFS on a home networkâ€Â, but that would be unfair to the authors of the existing answers. You asked a question, got answers, one of which was good enough for you to accept it; then you came up with another question, and decided to re-use your existing one. That doesn’t work too well with the Q&A format of StackExchange (but I imagine you know that given your SO experience).
– Stephen Kitt
Sep 12 at 12:48
This works when I turn my machine on with the other turned off. But if both are on and then the other goes off (i.e. the share is already mounted), then Nautilus, a Firefox "send file" window, and even a single
ls get frozen.– Rodrigo
Sep 11 at 13:14
This works when I turn my machine on with the other turned off. But if both are on and then the other goes off (i.e. the share is already mounted), then Nautilus, a Firefox "send file" window, and even a single
ls get frozen.– Rodrigo
Sep 11 at 13:14
@Rodrigo yes, that’s a feature of NFS and there isn’t much that can be done about it other than ensuring the shared volume is unmounted before the machine serving it is switched off. But you didn’t mention that requirement in your question :-/.
– Stephen Kitt
Sep 11 at 13:18
@Rodrigo yes, that’s a feature of NFS and there isn’t much that can be done about it other than ensuring the shared volume is unmounted before the machine serving it is switched off. But you didn’t mention that requirement in your question :-/.
– Stephen Kitt
Sep 11 at 13:18
1
1
@Rodrigo the question doesn’t mention that this is on a home network where machines are liable to be switched off with little warning. The question is about NFS mounts taking too long when the exporting machine is off; that has been addressed. If you have another question about dealing with mounted NFS volumes “going awayâ€Â, I suggest you ask a new question. A similar question exists already but it doesn’t have a satisfying answer IMO.
– Stephen Kitt
Sep 12 at 8:04
@Rodrigo the question doesn’t mention that this is on a home network where machines are liable to be switched off with little warning. The question is about NFS mounts taking too long when the exporting machine is off; that has been addressed. If you have another question about dealing with mounted NFS volumes “going awayâ€Â, I suggest you ask a new question. A similar question exists already but it doesn’t have a satisfying answer IMO.
– Stephen Kitt
Sep 12 at 8:04
Is there a home network where machines are never turned off? Yes, it seems I need to ask a new question, since in your country the energy seems to be "free". Tip: it's never free.
– Rodrigo
Sep 12 at 12:45
Is there a home network where machines are never turned off? Yes, it seems I need to ask a new question, since in your country the energy seems to be "free". Tip: it's never free.
– Rodrigo
Sep 12 at 12:45
@Rodrigo I’m not arguing about the energy part, I’m just saying that you’re changing the question. You could edit your question to turn it into “Please help me fix all the issues I have running NFS on a home networkâ€Â, but that would be unfair to the authors of the existing answers. You asked a question, got answers, one of which was good enough for you to accept it; then you came up with another question, and decided to re-use your existing one. That doesn’t work too well with the Q&A format of StackExchange (but I imagine you know that given your SO experience).
– Stephen Kitt
Sep 12 at 12:48
@Rodrigo I’m not arguing about the energy part, I’m just saying that you’re changing the question. You could edit your question to turn it into “Please help me fix all the issues I have running NFS on a home networkâ€Â, but that would be unfair to the authors of the existing answers. You asked a question, got answers, one of which was good enough for you to accept it; then you came up with another question, and decided to re-use your existing one. That doesn’t work too well with the Q&A format of StackExchange (but I imagine you know that given your SO experience).
– Stephen Kitt
Sep 12 at 12:48
 |Â
show 1 more comment
up vote
2
down vote
Perhaps consider using systemd automount?
I am using it and am happy with the way it works:
<ip-address>:/home/export/nfs /home/share/nfs nfs x-systemd.automount,noauto,_netdev 0 0
With this setup, the NFS share is not mounted at boot time, but automounts when you try to access the share (/home/share/nfs) in this trivial example.
answered Aug 31 at 16:23
maulinglawns
6,11621225
Thank you. Do I necessarily need thenoautoand_netdevoptions as well? From the manual it isn't clear to me.
– Rodrigo
Sep 1 at 1:26
@Rodrigo This was just an example, you can try to run without those options.
– maulinglawns
Sep 1 at 5:01
Yes, I'll try later. Thanks again!
– Rodrigo
Sep 1 at 8:10
I was too fast accepting your answer. When the other PC went off, Nautilus won't respond ever. Not even save as windows work. I had to use the other answer to make it work.
– Rodrigo
Sep 2 at 6:55
@Rodrigo Yes, thex-systemd.mount-timeoutoption can be useful as well.
– maulinglawns
Sep 2 at 7:13
 |Â
show 1 more comment
up vote
2
down vote
Perhaps consider using systemd automount?
I am using it and am happy with the way it works:
<ip-address>:/home/export/nfs /home/share/nfs nfs x-systemd.automount,noauto,_netdev 0 0
With this setup, the NFS share is not mounted at boot time, but automounts when you try to access the share (/home/share/nfs) in this trivial example.
answered Aug 31 at 16:23
maulinglawns
6,11621225
Thank you. Do I necessarily need thenoautoand_netdevoptions as well? From the manual it isn't clear to me.
– Rodrigo
Sep 1 at 1:26
@Rodrigo This was just an example, you can try to run without those options.
– maulinglawns
Sep 1 at 5:01
Yes, I'll try later. Thanks again!
– Rodrigo
Sep 1 at 8:10
I was too fast accepting your answer. When the other PC went off, Nautilus won't respond ever. Not even save as windows work. I had to use the other answer to make it work.
– Rodrigo
Sep 2 at 6:55
@Rodrigo Yes, thex-systemd.mount-timeoutoption can be useful as well.
– maulinglawns
Sep 2 at 7:13
 |Â
show 1 more comment
up vote
2
down vote
up vote
2
down vote
Perhaps consider using systemd automount?
I am using it and am happy with the way it works:
<ip-address>:/home/export/nfs /home/share/nfs nfs x-systemd.automount,noauto,_netdev 0 0
With this setup, the NFS share is not mounted at boot time, but automounts when you try to access the share (/home/share/nfs) in this trivial example.
answered Aug 31 at 16:23
maulinglawns
6,11621225
Perhaps consider using systemd automount?
I am using it and am happy with the way it works:
<ip-address>:/home/export/nfs /home/share/nfs nfs x-systemd.automount,noauto,_netdev 0 0
With this setup, the NFS share is not mounted at boot time, but automounts when you try to access the share (/home/share/nfs) in this trivial example.
answered Aug 31 at 16:23
maulinglawns
6,11621225
answered Aug 31 at 16:23
maulinglawns
6,11621225
answered Aug 31 at 16:23
maulinglawns
6,11621225
answered Aug 31 at 16:23
maulinglawns
6,11621225
6,11621225
Thank you. Do I necessarily need thenoautoand_netdevoptions as well? From the manual it isn't clear to me.
– Rodrigo
Sep 1 at 1:26
@Rodrigo This was just an example, you can try to run without those options.
– maulinglawns
Sep 1 at 5:01
Yes, I'll try later. Thanks again!
– Rodrigo
Sep 1 at 8:10
I was too fast accepting your answer. When the other PC went off, Nautilus won't respond ever. Not even save as windows work. I had to use the other answer to make it work.
– Rodrigo
Sep 2 at 6:55
@Rodrigo Yes, thex-systemd.mount-timeoutoption can be useful as well.
– maulinglawns
Sep 2 at 7:13
 |Â
show 1 more comment
Thank you. Do I necessarily need thenoautoand_netdevoptions as well? From the manual it isn't clear to me.
– Rodrigo
Sep 1 at 1:26
@Rodrigo This was just an example, you can try to run without those options.
– maulinglawns
Sep 1 at 5:01
Yes, I'll try later. Thanks again!
– Rodrigo
Sep 1 at 8:10
I was too fast accepting your answer. When the other PC went off, Nautilus won't respond ever. Not even save as windows work. I had to use the other answer to make it work.
– Rodrigo
Sep 2 at 6:55
@Rodrigo Yes, thex-systemd.mount-timeoutoption can be useful as well.
– maulinglawns
Sep 2 at 7:13
Thank you. Do I necessarily need the
noauto and _netdev options as well? From the manual it isn't clear to me.– Rodrigo
Sep 1 at 1:26
Thank you. Do I necessarily need the
noauto and _netdev options as well? From the manual it isn't clear to me.– Rodrigo
Sep 1 at 1:26
@Rodrigo This was just an example, you can try to run without those options.
– maulinglawns
Sep 1 at 5:01
@Rodrigo This was just an example, you can try to run without those options.
– maulinglawns
Sep 1 at 5:01
Yes, I'll try later. Thanks again!
– Rodrigo
Sep 1 at 8:10
Yes, I'll try later. Thanks again!
– Rodrigo
Sep 1 at 8:10
I was too fast accepting your answer. When the other PC went off, Nautilus won't respond ever. Not even save as windows work. I had to use the other answer to make it work.
– Rodrigo
Sep 2 at 6:55
I was too fast accepting your answer. When the other PC went off, Nautilus won't respond ever. Not even save as windows work. I had to use the other answer to make it work.
– Rodrigo
Sep 2 at 6:55
@Rodrigo Yes, the
x-systemd.mount-timeout option can be useful as well.– maulinglawns
Sep 2 at 7:13
@Rodrigo Yes, the
x-systemd.mount-timeout option can be useful as well.– maulinglawns
Sep 2 at 7:13
 |Â
show 1 more comment
Â
draft saved
draft discarded
Â
draft saved
draft discarded
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f466070%2fdebian-nfs-wait-too-long-when-the-other-debian-is-turned-off%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password