SOLVED NFS Share Data not found on server

[krvst]

I apologize ahead of time for my potential ignorance, but I have come to the conclusion that I need the advice of others.

We have (2) FreeNAS servers that we use for our backups in our office. One is located on-site and the other off-site, replicating through SSH. We are using ShadowProtect to acquire our backups and recently we've realized we weren't backing up our GNU\Linux VM's...

Setting up the ShadowProtect client on our end was simple, but we are met with the problem of having the data from the backups show up on the server itself. We have an NFS share setup and the software itself allows us to select this destination to send the backup files when completed from the Control Console for the software. I've mounted the NFS share as follows.

Code:

sudo mount -t nfs <Server IP>:/mnt/directory/of/share /mnt

The data shows up when you list files in that directory on the machine that is performing the backups, lets call this machine for the sake of explaining it better, Machine1.

Machine1, is running our backup software. The backup software is controlled remotely by Control1. The files that are made on Machine1, don't show up when the NFS is unmounted, and doesn't show up on the server in the data pool, however, when the NFS is remounted to Machine1, the incremental backups never stopped and continued to write to this path still not showing up in the data pool.

I've attached the screenshot of our NFS settings assuming all looks correct.



I have cursory knowledge of setting up, and configuring FreeNAS as I was thrust into dealing with this recently when our last Admin was let go. I'm extremely comfortable in the GNU\Linux and BSD terminal, familiar with navigating these systems, but I'm stumped. I'm sure it's something simple, but everywhere I've looked (man pages, Google, forums.freenas.org search, in that order lol) I must have just stumbled past it. Any help is appreciated, thanks everyone!

 

[joeschmuck]

You have not been ignored. You problem is very specific and I don't know who has the experience to give you the proper answers. If you found the answer, please post that this is fixed.

 

[krvst]

You have not been ignored. You problem is very specific and I don't know who has the experience to give you the proper answers. If you found the answer, please post that this is fixed.

Unfortunately, I still haven’t quite found a solution. I’ve been reading on shares and NFS issues.

I’ve also recently tried to change the share type and connect to it from a Windows machine and see if the files exist there and they do not.

I’m dreaming about this in my sleep now, lol.

 

[dlavigne]

Any errors in /var/log/messages?

 

[krvst]

Sorry for the late response @dlavigne;

Nothing in /var/log/messages on Machine1, on the server however, it's just the following output which appears to be normal stuff. (Outside of https://bugs.freenas.org/issues/21915 )

Code:

...
Dec  4 06:35:52 freenas alert.py: [common.pipesubr:66] Popen()ing: /usr/local/sbin/dmidecode -s baseboard-product-name
Dec  4 07:36:08 freenas alert.py: [common.pipesubr:66] Popen()ing: /usr/local/sbin/dmidecode -s system-product-name
...

I unmounted the NFS share from Machine1 and checked near every log file in /var/log/ to find nothing. Oddly enough, mount.today didn't actually contain anything I expected it too, learned a little somethin'.

 

[krvst]

Alright, after a few more attempts between trouble tickets, and preventing phishing emails to our users, I've found a solution.

Using mv for a file or folder within an NFS mount will apply the operation remotely.

unix.stackexchange

Once I issued a mv command on the directory I needed to have on the server, I checked and found that the contents were moved over and in proper order. (Albeit, I did issue the command with a rogue * and managed to move everything else...) It worked!

Again, the data was written to the mount point /mnt/<directory>... I had to do the following;

Code:

mv <directory> /mnt

Sorry for the trouble guys! Marking as solved here now..