Did you try the first version?

No go. I really think the problem is this error at boot on the server: server-pc exportfs[1589]: exportfs: Failed to stat /mnt/md0/data/: No such file or directory

If the server can't find that folder, it can't share it via NFS. I think we need to zero in on that error. I'm going to try Rickkkk's suggestion of editing my mdadm.conf file.

So I was thinking more about your suggestion of changing the mdadm.conf file but....since I -CAN- share out the entire array, would changing the mdadm.conf file for a single folder on there really make a difference?

Hey road_hazard,

Sorry if I wasn't clear with respect to my observations re: your mdadm.conf file. I don't think you need to edit it - it states itself that it is creating arrays using Debian standards. However, since you are trying to share it via nfs, I think the permissions it is creating by default on the directory and its subdirectories might need to be changed.

It's the execute privileges that have me concerned. If you make sure all levels from /mnt on down have at least "1" in the last position ("everyone" with execute-only permissions), that would eliminate THAT as a possible reason. Listing the contents of a directory is dependent on the user or group having at least execute permission.

The other suggestion concerned the statements in your exports file and the options: try adding "nohide" and "no_subtree_check" and re-exporting.

One last idea I just had concerns the method and options you're using to mount on the client side. Are you using fstab on your Antergos client or are you trying to mount manually via command line or file-manager ? ... The following are the options I use on my linux clients in their fstab files to connect to nfs shares on my server:

Let me know if any of this is still not clear.

I'd follow more experienced Rickkkk NFS admin

Just wanted to share another idea...
In the server it's possible to bind mount /mnt/md0/data on another mount point
eg:
Then add /mnt/data in /etc/exports

I don't know if that would work

Ok, that clears things up, thanks! Will do some playing around when I get more free time.

I'm mounting the share via the command line. (Don't want to do anything permanent to I at least get it working.)

The bind was successful but adding the bound path to my exports file and executing the exportfs command with the appropriate switches and even rebooting the server ended the same............... empty folder when accessed from the client. I'm not sure what else we can try at this point.

OK - let us know how it goes.

Cheers.

Please don't reboot after exports changes, it's unnecessary, really. The -r switch for exportfs command does all needed actions to refresh the server NFS shares (see exportfs manual)

Regarding the manual, I see that exportfs also reads entries from files in /etc/exports.d/, you have nothing here that could interfere?

The reboots were a .."since NOTHING is getting the NFS share working, might as well?!" type of thing. A Hail Mary pass if you will?

Just checked and there is no /etc/exports.d/ folder.

Well I got good news and bad news. The good news is, I got it working. The bad news is, I was using Antergos.

I scrounged up a bunch of old hard drives and created a RAID 6 array with mdadm and did everything else the exact. same. way. and it worked perfectly with Antergos. Like, textbook perfect.

My Kodi box and other Linux boxes in the house had zero problems seeing the NFS share that was sitting on /mnt/md0/data on Antergos. I used the same 'export' file, same everything. Only thing I can think of is the version of mdadm in Mint 18.3 (3.3? 3.4?) has some bug regarding NFS shares that 4.0 addresses.

I guess I could TRY updating mdadm in Mint but being a newbie, I'm wondering what would be easier. Moving to Antergos on my Plex server or installing the 4.x version of mdadm on Mint. I have a backup of my array but losing it and having to copy everything back would kind of suck.

I think that all the programs I need are in the Arch repos (or AUR) except for one maybe but no big deal.

Decisions, decisions.

Check my latest post. I got it working, but I was using Antergos.

Wow .. interesting ... there has to be something different in the resulting Antergos setup besides the fact that it's a different distro.

Have you compared the permissions on your /mnt and all subdirs between the 2 systems (Mint vs Antergos) ?

Great that you now have a working solution, mind you - good job getting there ! I'm not one to discourage you from using Antergos - as you can tell from my profile, Arch is my own system of choice.

Personally, I'm the type that wouldn't sleep well until I knew what the cause of the issue was. But that's me ... Up to you as to whether you want to pursue this, but if you do, I would start with the permissions issue I mentioned earlier.

Cheers - let us know what you decide.

I was re-reading one of your earlier messages and you talked about checking permissions and making sure "1" (the number 'one' I assume) is in the last position. See attached screen shot. Is that what you're referring to? (Last position after the drwxrblahblah stuff?)

Attached Thumbnails

 

*** WARNING - LONG POST ***

Hi road_hazard,

Yes - exactly that. In linux, there are several ways to express permissions - I'll try to summarize (apologies in advance if you already know all this stuff ...) :

- Permissions are structured around 3 entities:

• those reserved for the "user-owner" of a file or directory
• those reserved for the members of the "assigned group" of a file or directory
• those applying to "others"

- There are several common ways to express permissions on a files or directory, your picture shows one of them:

• The 1st character denotes the nature of the file or directory. If there is nothing (a dash) in that position, it is a file. If there is a "d", it is a directory. There are other identifiers, but those are the 2 most common ones.
  
• The next 3 groups of 3 characters each, are the permissions for, in order, user-owner, assigned group, and others. They are always in this order: rwx (for "read", "write" and "execute").
  
• At times, there may be an extra "+" character at the end of the whole string. This indicates that on top of the permissions specified by the preceding characters, there are also one or more specific "acl" s (access control list) on the file or directory. I won't get into that here, suffice to say that this is an additional, distinct method of assigning permissions to a file or directory where more granularity is required. If you're interested, the Arch Linux Wiki (as usual), has excellent documentation.

So for example, an entity whose permission string is: drwxr-x--x+ means:

• The object is a directory
  
• The user-owner of the directory has Read, Write and Execute (all) permissions
  
• The members of the assigned group have Read and Execute permissions, but not Write permissions
  
• Others have Execute permissions, but not Read nor Write.
  
• There are one or more acl's on the directory (these can be listed with the command "getfacl")

Another common way of expressing permissions, often used since it is much shorter in length, is by assigning numerical values to each of the permission types (read, write and execute) and expressing the "groups of 3 characters" with a single digit that is the sum of the values of its specific permission types. More specifically:

• Read permission ("r") is assigned a value of 4 (binary: 100)
• Write permissionm ("w") is assigned a value of 2 (binary: 010)
• Execute permission ("x") is assigned a value of 1 (binary: 001)

So to use our same example above:

• A directory with permission string drwxr-x--x would be expressed as "751" (user-owner: 4+2+1; assigned group 4+0+1; others: 0+0+1)

The assigned values make it so that a particular sum for a given triad can only represent one unique combination. So this is a type of "shorthand" notation, if you will, that is commonly used when discussing permissions.

More specifically with respect to your situation, the part that was concerning me was the possibility that mdadm was assigning 660 permissions (owner: read write but not execute, group: the same, others: no permissions at all) to one or several of your directories. This concerned me because one of the particularities of linux permissions is that execute permission is required to list the contents of a directory. This is why I was suggesting you verify that aspect.

Anyway, I apologize again for the long post - especially if this information wasn't particularly useful to you.

Let us know what you decide to do and feel free should you feel the need for any more assistance.

Cheers !