# rsync via nfs looses ownership for nobody:nobody

## lalebarde

Hi,

I want to perform backups via nfs. On the server, I set the /etc/exports like this : 

```
/home/lalebarde   PCLALEBARDE(rw,sync,no_subtree_check,no_root_squash)
```

On the client, /etc/fstab : 

```
PC2:/home/lalebarde     /PC2/backup/home/lalebarde   nfs   rw,auto,sync
```

Then I do the rsync  from root in the client :

```
# rsync -a --delete /home/lalebarde/ /PC2/backup/home/lalebarde/
```

As the result, all files in the backup are set user=nobody, group=nobody.

I thought from what I read on the web that no_root_squash was the key, but no. Of course, I reloaded the nfs server when I changed the exports. I also have the same users and groups, UIDs & GIDs.

Any clue ?

----------

## Jaglover

Methinks everything falls into place when you have user lalebarde in remote machine with same UID as in your local machine. And no_root_squash is really not a feasible option, I use portage on NFS for instance and it is owned by user portage:portage in remote box which is even not running Linux. Just do your backups as user and everything will be fine.

----------

## lalebarde

Thanks for your answer Jaglover.

 *Jaglover wrote:*   

> Methinks everything falls into place when you have user lalebarde in remote machine with same UID as in your local machine. 

 That's what I do have.

 *Jaglover wrote:*   

> Just do your backups as user and everything will be fine.

 It is not a solution for me since my directories belong to several groups, depending on what I want to share with whom.

----------

## Jaglover

Shouldn't all rights be preserved if you have same groups (with same GID) in the remote box?

----------

## krinn

if your user is root and you end with uid:gid of nobody, it's exactly what the root_squash should do.

your export is then not understood as you think.

you might try exportfs -v on server to see what options are set the way you think they should.

and you might check your server for which version of nfs you are using on server and client to mount the share, for a nfsv4 server this is not a valid export directive, as you should have a root directory with fsid=0 and subdirectories directives.

for some obscure reasons i really don't know why, let's say compatibilities, they accept nfsv3 style of exports and the server try to use that for both v3 and v4, this cause more troubles then help, as a v3 client will mount it right, but a v4 will find it totally wreck as non-standard to v4.

what you could try, is forcing the client to use v3, i think it's with -o nfsver=3 parameter, this "should" gave you a more permissive nfs server.

you could lower your security too by passing the group uid you wish to your export filesystem with anongid=guidyouwish to let your root_squashing setting the guid you wish instead of the default nobody guid

or switch to full nfsv4 with your clients and server configure to use idmapd with the same domain.

----------

