This follows on from the thread started in [NFS Advanced Edit Incorrectly Checks Existence of Shares - #8 by Walt]. Due to the severity of the bug recently discovered it needs to have its own topic.
As described in the referenced thread, I used a workaround to add two lines to
/etc/exports via the NFS Advanced Edit button in Rockstor. Both lines began with “/export/…”. This did not appear to cause any issues. (See the thread referenced above for all the details.) Recently I tried exporting a third subdirectory using that same method and that bug returned, along with an additional corruption of the filesystem.
For clarity, this will be explained with the following example.
- Consider a share named AAA.
- There are folders in AAA named bbb, ccc and ddd.
- The NFS exports are:
- When ddd was not exported, all three exports mounted fine on the client. “ls” of the AAA mountpoint on the client listed directories /bbb, /ccc and /ddd, along with other contents in AAA. “ls” of mountpoints of /bbb and /ccc listed the expected contents of those directories. “ls /mnt2/AAA” typed from the console of the exporting server also listed the expected contents. AAA was also exported via Samba and its contents were available on a Windows PC where it was exported to.
- When the export of /ddd was added, all four NFS exports mounted successfully on the Linux client. “ls” of the mountpoint of AAA returned an empty list. “ls” of the mountpoints of /bbb and /ccc returned empty lists. “ls” of the mountpoint of /ddd showed the expected contents of /ddd. The contents of /ddd were readable, but the transfer rate was slow. On the console of the server, “ls /mnt2/AAA” returned an empty list. From the Windows PC, AAA also appeared to be empty.
This means that the NFS bug is not only affecting NFS it is also corrupting something in the filesystem of the host. It is not known what would happen if data was written to the file system while it was messed up like this, but data loss or corruption of the share on the drive could reasonably be expected.
The visibility and normal function of the share returned when
/export/AAA/ddd was removed. From the server console, “ls /mnt2/AAA” returned the expected contents. From the Windows PC, AAA then showed the expected contents.
In conclusion, NFS, as implemented in openSUSE as shipped with Rockstor 4.5.6, has a serious bug that has the potential to corrupt the filesystem of the exporting server. The bug shows up sporadically when exporting subdirectories of a filesystem. So far I’ve observed no instances of this issue when only the top-level of a share is exported.