1

Whenever I make an NFS export on a folder off my home directory I get the error below (appreciate this example is too brief, but the next set of code shows how I got here):

$ sudo exportfs -ar
exportfs: /export/test does not support NFS export

Here is what I've done in detail:

## Create the bind mount ##
$ sudo  mount --bind /home/john/test /export/test

## Verify original /home/john/test folder exists ##
john@john:~/test$ cd ~/
john@john:~$ ls -l | grep test
drwxrwxr-x  2 john john  4096 Feb  9 13:33 test

## Check what files exist in this folder and confirm they are in the bind location ##
john@john:~$ cd test
john@john:~/test$ ls 
f  test  testfile

## Verify bind location folder exists & that the same files are in this location ##
john@john:~/test$ cd /export/test
john@john:/export/test$ ls
f  test  testfile

## Ensure export file is exporting the bind location ##
john@john:/export/test$ grep test /etc/exports
/export/test 192.168.0.0/24(rw,sync,root_squash,no_subtree_check)

## Re-export shares to get the /export/test nfs share on the network ##
john@john:/export/test$ sudo exportfs -ar
exportfs: /export/test does not support NFS export

As you can see. When I try to re-export my share, it throws the error above. After the testing below, I found that this only happens when trying to export anything linked, or directly on my /home/john/ directory. I don't know why.


##################### Testing using a directory outside of /home #####################

Here I try and use the NFS share on a new directory "/test" without a bind mount, and it works:

#note, continuing from the bash commands above#
john@john:/test$ cd ..
john@john:/$ sudo umount /test
john@john:/$ ls /test
test
john@john:/$  sudo exportfs -ar
john@john:/$ 

######## Testing using a share from a directory in /home (without a bind-mount) #########

Here I made a share on a directory off of my home directory (as I suspect it's the home directory mounts having the issue), without any binds, which doesn't work

john@john:~$ mkdir test-nobind
john@john:~$ cd test-nobind/
john@john:~/test-nobind$ touch file1 file2
john@john:~/test-nobind$ ls -l
total 16
-rw-rw-r-- 1 john john 0 Feb  9 19:23 file1
-rw-rw-r-- 1 john john 0 Feb  9 19:23 file2
john@john:~/test-nobind$ cd ..
john@john:~$ sudo nano /etc/exports ###added line to export this folder
john@john:~$ grep test /etc/exports
/home/john/test-nobind 172.31.16.0/24(rw,sync,root_squash,no_subtree_check)
john@john:~$ sudo exportfs -rav
exporting 172.31.16.0/24:/home/john/test-nobind
exportfs: /home/john/test-nobind does not support NFS export

As you can see, I have the same error as my original post where exportfs says "does not support NFS export". So it's my home directory causing the problem. My /etc/cryttab file is empty, so I don't believe I have any encryption running. I want to know why I get this error?


Extra checks:

john@john:/home$ df $HOME
Filesystem            1K-blocks     Used Available Use% Mounted on
/home/john/.Private 106992680 81417972  20116688  81% /home/john

john@john:~$ mount | grep /home/john
/home/john/.Private on /home/john type ecryptfs (rw,nosuid,nodev,relatime,ecryptfs_fnek_sig=b15035efe9091f4e,ecryptfs_sig=05afa3a5d0c7b155,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs)
5
  • Is the behaviour any different if you start with a test directory outside your user's home directory? Feb 9, 2019 at 17:42
  • Hi @steeldriver I have isolated the fault to being shares that are hosted off the home directory. Whenever I try to share anything off /home/john/ , then exportfs comes up with the same error: "does not support NFS export". Do you know why this would be?
    – john smith
    Feb 9, 2019 at 19:30
  • No, tbh I was really just spitballing... unless your home directory is encrypted? in which case I could imagine ecryptfs not playing nicely with nfs Feb 9, 2019 at 20:47
  • No, no encryption as car as I can tell. Nothing is in /etc/crypttab.
    – john smith
    Feb 9, 2019 at 21:48
  • We got this error on RHEL 6 (old, I know) when someone accidentally set the system clock to the year 2050. Presumably a Y2K38 problem.
    – Nemo
    Apr 7, 2022 at 0:18

0

You must log in to answer this question.

Browse other questions tagged .