# Cannot receive property on remote system.



## Klavi (Jan 25, 2013)

Hi,

I have two FreeBSD 9.0 boxes with two large ZFS pools on, box1 and box2

I have an automated snapshot script zfSnap running to make snapshot every 15 min on box1.

The I have a script zfs-backup that should sent the snapshots from box1 to box2.

I have set it up with ssh keys and this works. On the rec*ei*ving box2 I have following allows for the user account used to make the transfer:


```
box2% zfs allow data/backups
---- Permissions on data/backups -------------------------------------
Local+Descendent permissions:
        user zfsbackup create,destroy,mount,receive,rename,rollback
---- Permissions on data ---------------------------------------------
Local+Descendent permissions:
        user zfsbackup create,mount,receive
```


```
158  if ! /sbin/zfs send -R -I $snap1 $DATASET@$snap2 | \
159  ssh $REMUSER@$REMHOST /sbin/zfs receive $VERBOSE_STRING $RECV_OPT -F $REMPOOL; then
160  echo 1>&2 "Error sending snapshot."
```

It will run and send the snapshots, but I get following failures for each snapshot received:


```
cannot receive xx.tech:backup-target property on data/backups/LTS: permission denied
cannot receive sharenfs property on data/backups/LTS: permission denied
cannot receive mountpoint property on data/backups/LTS: permission denied
cannot mount '/data/backups/LTS': failed to create mountpoint
Error sending snapshot.
```

I have following set on ZFS on box1

```
box1% zfs get all data/LTS
NAME      PROPERTY                  VALUE                     SOURCE
data/LTS  type                      filesystem                -
data/LTS  creation                  Thu Nov 15  9:37 2012     -
data/LTS  used                      14.4G                     -
data/LTS  available                 4.85T                     -
data/LTS  referenced                14.3G                     -
data/LTS  compressratio             1.00x                     -
data/LTS  mounted                   yes                       -
data/LTS  quota                     none                      default
data/LTS  reservation               none                      default
data/LTS  recordsize                128K                      default
data/LTS  mountpoint                /LTS                      local
data/LTS  sharenfs                  off                       local
data/LTS  checksum                  on                        default
data/LTS  compression               off                       default
data/LTS  atime                     on                        default
data/LTS  devices                   on                        default
data/LTS  exec                      on                        default
data/LTS  setuid                    on                        default
data/LTS  readonly                  off                       default
data/LTS  jailed                    off                       default
data/LTS  snapdir                   hidden                    default
data/LTS  aclmode                   discard                   default
data/LTS  aclinherit                restricted                default
data/LTS  canmount                  on                        default
data/LTS  xattr                     off                       temporary
data/LTS  copies                    1                         default
data/LTS  version                   5                         -
data/LTS  utf8only                  off                       -
data/LTS  normalization             none                      -
data/LTS  casesensitivity           sensitive                 -
data/LTS  vscan                     off                       default
data/LTS  nbmand                    off                       default
data/LTS  sharesmb                  off                       default
data/LTS  refquota                  none                      default
data/LTS  refreservation            none                      default
data/LTS  primarycache              all                       default
data/LTS  secondarycache            all                       default
data/LTS  usedbysnapshots           10.2M                     -
data/LTS  usedbydataset             14.3G                     -
data/LTS  usedbychildren            0                         -
data/LTS  usedbyrefreservation      0                         -
data/LTS  logbias                   latency                   default
data/LTS  dedup                     off                       default
data/LTS  mlslabel                                            -
data/LTS  sync                      standard                  default
data/LTS  refcompressratio          1.00x                     -
data/LTS  xx.tech:backup-target     basename                  local
```

sharenfs is off!

I have set it up to send with base name, not full path, as pool name on Box1 is data/LTS and it is received on data/backups on box2 -> data/backups/LTS@2013-01-24....

What do I miss here, since *I* get these permission denied?


----------



## phoenix (Jan 26, 2013)

Why are you using -R?


----------



## Klavi (Jan 26, 2013)

I use -R inorder to preserve properties.

I found that I missed to allow following on the receiving machine:

mountpoint, sharenfs and userprop via the zfs allow command.


```
# zfs allow zfsbackup mountpoint,sharenfs,userprop data/backups
```

now it seems like i only need to find out why it would not mount the filesystem.


----------



## adaugherity (Jan 29, 2013)

I'm glad you found my zfs-backup script useful (and it's good to know it works on FreeBSD), and sorted out the userprop issue.  (Ironically, that's how I found this thread -- I finally upgraded a server to use this newer version of the script rather than the 3-year-old private version I had been using, and hit the same issue.)

Feel free to submit pull requests or issues via GitHub.  I know it would take some minor tweaks but hopefully it's just little stuff like sudo vs. pfexec.

You may need to zfs allow mount on the receiving end to have the filesystems mounted properly afterwards (I have it in my zfs allow, but I don't remember exactly why -- perhaps it was for this very reason).  I just updated the documentation to at least mention allowing userprop, and granting the permissions necessary to resolve any errors produced by the initial receive.


----------



## Klavi (Jan 30, 2013)

I run as an non root user, that creates the problem with mounting, so I simply added the -u on the zfs receive command.

It might be possible to tweak the permissions so mounting is allowed for this user, but I do not need it to automate, so I manually mount.

I was more thinking of including a delete schem, so when back-up has been performed, it will look at which snapshoots that are present at both computers and then delete accordingly to, so if for some reason a bad connection will not cause the snapshoots to be out of sync and make it impossible to do incremental backup's, which could be a problem with large filesystems.

I use the ZFSnap script that on the naming of the snapshots indicate the time to live for the snapshot. important is make sure to sync the delete of snapshots so, one computer deletes automatically all snapshots present on the other and thereby make it impossible to do an incremental backup.

This along with an warning system to syslog, nagios or email if script failes to backup.


----------

