|(14 intermediate revisions by 6 users not shown)|
exportfs- error== |+|
|−|I applied this article to my server today and I found an exportfs- error: in /etc/exports a range of clients has to be described like 'ip/netmask'. CORRECT WAY: '192.168.0.0/255.255.255. 0', whereas the example on this page throws an error.--[[User:Zenlord|Zenlord]] 08:34, 30 September 2009 ( EDT) |+|
this to and an -to be . . , the on ()
| || |
|−|==SSH tunnelling== |+|
|−|Since NFSv4 is a insecure protocol (doesn't encrypt traffic), what about adding some info about tunneling it with SSH? This link is very useful: http://blogs.sun.com/shepler/entry/tunneling_nfs_traffic_via_ssh |+|
|−|The only problem, rpcbind has to be also tunneled. |+|
is a , is be .
| || |
|−|==client ip address/ranges== | |
|−|Also mentioning that we need to put client ip address/ranges in the /etc/exports might be a good idea for people using NFS for the first time. [[User:Inxsible|Inxsible]] | |
| || |
Mounting the partitions on the client == |+|
tried following the wiki but it seems that, for the client, it is no longer necessary to start rpcbind or nfs- common services.--[[User: Angheloko| Angheloko]] 11: 44, 8 October 2011 ( EDT) |+|
I the that , the ,
[[User :|]]:, ()
Revision as of 07:24, 18 December 2013
I think that
/etc/systemd/system/auto_share.service should contain the following line after
The rationale for this is that you need to wait for the network to be up and running before attempting an NFS connect from client-side. You also need to perform the NFS mountings before making user sessions available, because the latter may be dependent on the former. For example, my bash profile is stored on a remote server, so I need NFS drives mounted before I even attempt a login. On some systems, maybe the whole
home directory is on a different computer (as would be the case for thin clients), meaning that they should definitely be mounted before users can log in.
You need to enable
NetworkManager-wait-online.service like so:
# systemctl enable NetworkManager-wait-online
I can't help thinking that this is a bit of a kludge in any event, and is a scenario that should be handled automatically by
/etc/systemd/system/auto_share.service is a bad place to create the file. Instead, do it in the standard way by creating it as
/lib/systemd/system/auto_share.service and re-enabling it using the command
# systemctl reenable auto_share.service
--Blippy (talk) 20:24, 8 September 2013 (UTC)
Make iptables.rules syntax more clear
For me the file /etc/iptables/iptables.rules didn't exist so I created it with the lines in Firewall configuration section. After that iptables failed to start, giving syntax errors. After some searching, I added "*nat" at top and "COMMIT" at bottom of the file, and it worked.
Will adding this info make it more clear or should we leave it way it is?
axper (talk) 18:48, 28 September 2013 (UTC)
If /etc/iptables/iptables.rules didn't exist then you didn't use a firewall and there was no need to do any configuration to enable NFS access through a firewall. I don't think we should add too much information about how to configure a firewall in general on the NFS page.
I checked the ssh page to see how they address firewalls (ssh was the first thing I could think of that probably needs some firewall configuration) and they use command like
# iptables -I INPUT 1 -p tcp --dport 22 -j ACCEPT
instead of editing iptables.rules.
Should we change the article to show commands similar to above rather than talking about /etc/iptables/iptables.rules or should we just keep the one sentence mentioning the port numbers and protocols?
Crawlman (talk) 07:24, 18 December 2013 (UTC)