On 2019-12-08 12:15, Tim via users wrote:
On Sun, 2019-12-08 at 11:11 -0500, Bob Goodwin wrote:
I am still unable to get the NFS server to run -
[root@NFS-Server bobg]# systemctl status nfs-server
● nfs-server.service - NFS server and services
Loaded: loaded (/usr/lib/systemd/system/nfs-server.service; enabled; vendor preset: disa>
Drop-In: /run/systemd/generator/nfs-server.service.d
└─order-with-mounts.conf
You might want to look at that file:
/run/systemd/generator/nfs-server.service.d/order-with-mounts.conf
.
[root@NFS-Server bobg]# cat
/run/systemd/generator/nfs-server.service.d/order-with-mounts.conf
# Automatically generated by nfs-server-generator
[Unit]
RequiresMountsFor=/nfs4exports/home
I'm not familiar with any of that?
Active: failed (Result: exit-code) since Sun 2019-12-08 10:07:27
EST; 1min 43s ago
Process: 12686 ExecStartPre=/usr/sbin/exportfs -r (code=exited, status=1/FAILURE)
Process: 12687 ExecStopPost=/usr/sbin/exportfs -au (code=exited, status=0/SUCCESS)
Process: 12688 ExecStopPost=/usr/sbin/exportfs -f (code=exited, status=0/SUCCESS)
CPU: 15ms
Look at man exportfs: The -r option is about re-exporting directories,
-au would be un-exporting all exported directories, the -f is about
flushing the export tables. It also mentions other files used by the
system: /var/lib/nfs/etab and /var/lib/nfs/rmtab (you could check if
they're mangled, and possibly just erase them to wipe your slate
clean).
It does look like the restart ultimately succeeded.
I've tried varying the exports -
[root@NFS-Server bobg]# cat /etc/exports
# /nfs4exports/home
192.168.2.0/24(rw,sync,insecure,no_root_squash,no_subtree_check)
# /nfs4exports/
192.168.2.0/24(rw,sync,insecure,no_root_squash,no_subtree_check)
# /home/egreshko
192.168.0.0/16(rw,sync,insecure,no_root_squash,no_s
Above is an example provided by Ed, below is a similar line with my
address, just a trial to see if NFS might start with that in place, it
did not.
/home/bobg
192.168.2.0/24(rw,sync,insecure,no_root_squash,no_subtree_check)
You're absolutely sure those filepaths are correct? And do you have
line breaks in the file, as above? I've never seen an exports file
like that. I'm sure you don't have Ed's egreshko directory on your
system. I'd try a simple test case, leave the home directory alone for
a while, simplify your exports file.
mkdir /testing
touch /testing/testfile
(even better make a testfile that has some content you can read)
And inside your /etc/exports file, something simple like:
/testing 192.168.0.0/16(rw,sync)
That would allow anything with a 192.168 prefixed LAN IP address to
connect. Your LAN is using those addresses?
You'll need to allow NFS traffic through your firewalls, on the server
and the clients. If you're on a safe network, you can disable your
firewalls, otherwise enable the appropriate ports on your firewalls
(ultimately, this is what you want to do).
On my computer, I can test the server on itself. I can use NFS to
access its own exports. That allows me to test the server, if a client
is acting up.
When you have a working NFS server, you can make any changes to your
/etc/exports file take effect with this command, instead of simply
restarting the NFS server:
exportfs -ra
After each change to exports I did systemctl restart nfs-server
without success ...
[root@NFS-Server bobg]# systemctl restart nfs-server
Job for nfs-server.service canceled.
What do you get from: systemctl stop nfs-server
Hopefully it stops successfully.
And, afterwards: systemctl status nfs-server
And you should get a successful result about it being halted.
You could try reversing the direction of your tests, share something
from the other PC, instead. See if you get different results.
Depending on what scheme you're using, to access something over NFS,
your numerical User ID will have to be the same on the server and
client (it's numerical numbers it cared about, not the username).
Though world-readable directories and files shouldn't face that
restriction.
I'm running a mixed LAN with CentOS and Fedora, so my system may have
some differences from a Fedora only LAN.
--
Bob Goodwin - Zuni, Virginia,
Fedora Linux-31 XFCE
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx
