Replication of NFS mounted directory with or without root squashing.

Why it is not a good idea to replicate an nfs mounted directory with or without root squashing.

NFS replication of nfs mounted directories should pay a lot of attention.

The problem with NFS file replication on Linux (and others)

I spent the last thirty minutes tracking what I believed was a serious problem with AIX file replication.
It turned to be a false bug alarm; nevertheless I was like “A dawg chasing his tail …”. So my fellow engineers and systems staff, I will spare you that pain so we can transfer what we transfer easily without problems.

Before I confuse you: let me give you the relevant parts from my configuration before I delve into the replication issue:

    link name="link1":

        sender:  hostname="localhost" alias="*" password="*******"
        receiver:  hostname="jamaica" storepath="/vault/nyc/aggregate102"

See more info about file replication configuration.

Now I tried to replicate the following system: /home/elhaddi/sandbox

eh@aix:~/enduradata/edpcloud/etc$ df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/hd4                262144    210912     51232  81% /
/dev/hd2               2162688   2018128    144560  94% /usr
/dev/hd9var             458752    299104    159648  66% /var
/dev/hd3                131072     18892    112180  15% /tmp
/dev/hd10opt            393216    343564     49652  88% /opt
/dev/hd1              15532032   3089912  12442120  20% /home
eh_linux19:/home/elhaddi/sandbox  66055932  60742428   1958064  97% /home/elhaddi/sandbox

Notice that I am nfs mounting my sandbox from my linux cluster node called eh_linux19.

So I want to transfer files from the NFS mounted diretory /home/elhaddi/sandbox to host jamaica.
That is easy, doable but not when I am in a panic mode.

Once I tried to replicate /home/elhaddi/sandbox to jamaica I saw lots of failures in eddist.log and in ed_sender*.log

In eddist.log, you will see:

tail -f ed_sender*log:
--------------------

ERROR: ed_util.c(#04874) [ed_sender(9044114) [Thu Mar 27 13:42:55 2014] /home/eh/sandbox/trunk/tamda/manuals/programs/html/bg_head_middle.jpg: Permission denied[13]
ERROR: ed_util.c(#04874) [ed_sender(9044116) [Thu Mar 27 13:42:59 2014] /home/eh/sandbox/trunk/tamda/manuals/programs/html/bg_head_middle.jpg: Permission denied[13]

tail -f eddist.log
--------------------------
Well too many to list: But you basically get access denied there as well.

One way to solve this problem is to change /etc/exports on the nfs server side to add no_root_squash to the list of export options.

/home/elhaddi/sandbox @localdev(rw,no_root_squash)

That fixes it! yes it does but beware of what no_root_squash will allow to your milieu!

Warning about NFS file replication

By using NFS file replication in this case, you cut your costs (by paying one license less but you reduce your flexibility) but you increase your security risks.

I believe this problem affects ftp, scp, cp and anyone who wants to read/write from NFS (user nobody :-).