# zfs receive -u shouldn't mount received filesystem, right?



## uisge (Jan 7, 2013)

Hi --

I'm trying to send one server's content to another server by applying:


```
zfs send -R zpool@SAVEME | ssh user@otherserver zfs receive -vFdu zpool/BACKUP
```

According zfs(8) I did expect that ...


```
|      zfs receive [-vnFu] [-d | -e] filesystem
[...]
|         -u      File system that is associated with the received stream is
|                 not mounted.
```

... wouldn't mount received filesystems, but I do see e.g. ...


```
| zpool/BACKUP/usr       643M  1.23T   642M  /usr
```

... plus all other filesystems sent, accordingly.

What am I misunderstanding? Shouldn't the "-u" switch omit mounting zpool/BACKUP/usr/local at all? I do need such functionality, otherwise those mounted directories will render my receiving server unusably ... "zfs library not found"

This is 9.1-RELEASE.

Thanks.


----------



## ondra_knezour (Jan 7, 2013)

> -R
> 
> Generate a replication stream package, which will replicate the specified  filesystem,  and  all descendent file systems, up to the named snapshot. When received, all  properties,  snapshots, descendent file systems, and clones are preserved.
> 
> If the -i or -I flags are used in conjunction with the -R flag, an incremental replication stream  is  generated.  The  current values  of  properties, and  current snapshot and file system names are set when the stream is received. If the  -F  flag  is specified when this stream is received, snapshots and file systems that do not exist on the sending side are destroyed.



*The  current values  of  properties,	and  current  snapshot and file system names are set when the stream is received.* What will occur, when mounted property on receiving side will be restored?


----------



## uisge (Jan 7, 2013)

ondra_knezour said:
			
		

> *The  current values  of  properties,	and  current  snapshot and file system names are set when the stream is received.* What will occur, when mounted property on receiving side will be restored?



I do understand the manual page, that all properties including mountpoint are *sent* by "-R", but I do also understand that by using "-u" while *receiving* the filesystem will *not* be mounted although there is a property mountpoint sent. Wrong?

Well, I will try to get rid of "-R" then.


----------



## Savagedlight (Jan 7, 2013)

I think -u means that the file system won't be mounted once received. Not sure what happens on export/import or reboot, though.
The mountpoint is just a property, indicating where it'll be mounted to when that happens.


----------



## kpa (Jan 8, 2013)

You can import the pool at the receiving end with altroot set to let's say /mnt so the directory hiercarchy will be rooted at /mnt:

`# zpool import -R /mnt zpool`

Or import the pool without modifying altroot but tell zpool(8) not to mount any filesystems:

`# zpool import -N zpool`

Edit: Do you have a separate ZFS pool for back ups at the receiving end? If you're receiving the back up on the system pool ignore my advice.


----------



## uisge (Jan 8, 2013)

Savagedlight said:
			
		

> I think -u means that the file system won't be mounted once received.



Yes, that's my interpretation of the manual page as well.



			
				Savagedlight said:
			
		

> The mountpoint is just a property, indicating where it'll be mounted to when that happens.



But in my case the filesystem is being mounted after receival, although the "-u" should prevent that:


```
Source at sending server:
zpool/usr              643M  1.23T   642M  /usr

After receival:
zpool/BACKUP/usr       643M  1.23T   642M  [B]/usr[/B]
```

In the end I will end up with a server having two /usr mountpoints, one "belonging" to the receiving server, and one mounted "on top" of that mountpoint by zfs receive.

That will render my receiving server unusably. I will get a "zfs library not found" for every command applied, afterwards. I am unsure whether my interpretations are correct, but I need to find a way (besides rsync) to prevent sent filesystems from being mounted upon receival. Any help will is highly appreciated.


----------



## kpa (Jan 8, 2013)

Try this on the receiving system

`# zfs set canmount=noauto zpool/BACKUP`


----------



## uisge (Jan 8, 2013)

kpa said:
			
		

> `# zfs set canmount=noauto zpool/BACKUP`



Yesterday, I did try `# zfs set mountpoint=none zpool/BACKUP` but that didn't work out. I was already thinking about creating the complete filesystem tree and setting all filesystems to mountpoint=none or mountpoint=/BACKUP/...

But, thanks, I will give it a try (tonight).


----------



## usdmatt (Jan 8, 2013)

```
| zpool/BACKUP/usr       643M  1.23T   642M  /usr
```

This is the output from a zfs list showing the mountpoint property, but is the file system actually mounted? I've just tested on a 9.0-RELEASE system and it works as expected. The mountpoint property is sent with the snapshot, but the file system is not mounted and does not appear in mount or df output.

The problem you probably will have though is that it may well get mounted if the backup system reboots (big flaw with -u really, they should of made this option modify the canmount property directly). As kpa says, the easiest way to fix that is to set canmount=noauto/off on the backup system. As far as I'm aware, this will only need doing the first time when the backup file system is first created. I also usually suggest setting readonly=on so that you don't accidently change the backup, stopping incremental sends from working.

Oracle ZFS has had a -o option for zfs recv for quite a while now which allows setting properties such as canmount/compress/etc on the fly as part of a receive. I thought this was old enough that it's in the open version as well but doesn't look like it, hopefully it'll be added at some point, it's extremely useful.


----------



## uisge (Jan 8, 2013)

usdmatt said:
			
		

> ```
> | zpool/BACKUP/usr       643M  1.23T   642M  /usr
> ```
> 
> This is the output from a zfs list showing the mountpoint property, but is the file system actually mounted?



Yes, it is, checked with mount and df.



> I've just tested on a 9.0-RELEASE system and it works as expected. The mountpoint property is sent with the snapshot, but the file system is not mounted and does not appear in mount or df output.



Interesting. I am struggeling at 9.1-RELEASE.



> The problem you probably will have though is that it may well get mounted if the backup system reboots



Yes. That is an issue I would have run into if I wouldn't have failed before ;-) I just didn't think about that. So, thanks to everybody mentioning it.



> I also usually suggest setting readonly=on so that you don't accidently change the backup, stopping incremental sends from working.



I did so already. Although I do not understand why one should do so ;-)


----------



## tcreech (Oct 1, 2013)

I just independently/accidentally recreated @uisge's original scenario. I was trying to send a copy of my root filesystem to a child filesystem with the following:

`sudo zfs send -vR zroot@tobeadm | sudo zfs recv -vduF zroot/ROOT/91_01102013`

zroot/ROOT has no @tobeadm snapshots so it is not recursively sent. My plan was to do the send with the filesystems under zroot/ROOT temporarily unmounted, and then immediately change the mountpoint of zroot/ROOT/91_01102013 so that I won't have it mounted at / upon reboot.

Unfortunately, `zfs recv` DID mount over my live /, leaving empty mountpoints for /usr, /lib, /proc, /dev, etc., and thus a mostly non-functional machine.

The question is, is this a bug, or is @ondra_knezour's interpretation correct? Expecting the user to know that the mountpoint property needs to be sent separately and that `zfs recv` setting this will mount the filesystem even despite `-u` seems excessively tricky. I feel this should at least be clarified in the man page.


----------



## Sebulon (Oct 1, 2013)

I have prevented this behaviour by first making sure to: `# zfs set canmount=noauto zfs/filesystem`.

On all filesystems, this property does not seem to "like" inheritance for some reason. You can have ZFS mountpoints set but you also need to add entries in fstab for them to get mounted on reboot in the sending, source system. And to `zfs recv` with -u. Having canmount=noauto and manual fstab entries could cause problems with other techniques, like beadm, so beware.

When all else fails, set 
	
	



```
mountpoint=legacy (or none)
```
 on the receiving, destination system.

/Sebulon


----------



## tcreech (Oct 3, 2013)

Thanks for the workaround, @Sebulon.

I was interested in whether or not this is a bug, so I compared behavior with OmniOS (http://omnios.omniti.com). It seems that OmniOS behaves as @uisge and myself originally expected, leading me to believe that this is actually a bug in FreeBSD's ZFS. (I.e., received filesystems are unexpectedly mounted with "-u" on FreeBSD, but are not mounted on OmniOS.)

Unless anyone here thinks I shouldn't, I'll hopefully get some time and submit a bug report.


----------



## swills@ (Dec 28, 2013)

*Re: zfs receive -u shouldn't mount received filesystem, righ*

Did you ever submit a PR for this? If so, what was the number?


----------



## Kajanos (Aug 12, 2016)

Problem still occurs.

For example


```
[root@FreeBSD ~]# zfs list
NAME                 USED  AVAIL  REFER  MOUNTPOINT
zroot               5.79G  11.5G    96K  /zroot
zroot/ROOT          2.38G  11.5G    96K  none
zroot/ROOT/default  2.38G  11.5G  2.38G  /
zroot/tmp            224K  11.5G   144K  /tmp
zroot/usr           3.41G  11.5G    96K  /usr
zroot/usr/home       156K  11.5G   156K  /usr/home
zroot/usr/ports     2.87G  11.5G  2.87G  /usr/ports
zroot/usr/src        548M  11.5G   548M  /usr/src
zroot/var            808K  11.5G    96K  /var
zroot/var/audit       96K  11.5G    96K  /var/audit
zroot/var/crash       96K  11.5G    96K  /var/crash
zroot/var/log        236K  11.5G   156K  /var/log
zroot/var/mail       188K  11.5G   116K  /var/mail
zroot/var/tmp         96K  11.5G    96K  /var/tmp
```


```
zfs send -Rv zroot@replica1 | ssh root@gentooqa zfs recv -vudF freebsd
```


```
GentooQA_ZFS / # zfs list
NAME                            USED  AVAIL  REFER  MOUNTPOINT
freebsd                        4.28G  15.0G    19K  /zroot
freebsd/ROOT                   1.96G  15.0G    19K  none
freebsd/ROOT/default           1.96G  15.0G  1.96G  /
freebsd/tmp                      32K  15.0G    32K  /tmp
freebsd/usr                    2.32G  15.0G    19K  /usr
freebsd/usr/home               36.5K  15.0G  36.5K  /usr/home
freebsd/usr/ports              1.94G  15.0G  1.94G  /usr/ports
freebsd/usr/src                 389M  15.0G   389M  /usr/src
freebsd/var                     156K  15.0G    19K  /var
freebsd/var/audit                19K  15.0G    19K  /var/audit
freebsd/var/crash                19K  15.0G    19K  /var/crash
freebsd/var/log                  58K  15.0G    58K  /var/log
freebsd/var/mail                 22K  15.0G    22K  /var/mail
freebsd/var/tmp                  19K  15.0G    19K  /var/tmp
tank                           25.4G   104G    96K  /
tank/gentoo                    21.1G   104G    96K  /gentoo
tank/gentoo/home                116K   104G   116K  /home
tank/gentoo/portage            5.85G   104G  1.06G  /usr/portage
tank/gentoo/portage/distfiles  3.05G   104G  3.05G  /usr/portage/distfiles
tank/gentoo/portage/packages   1.74G   104G  1.74G  /usr/portage/packages
tank/gentoo/root               14.0G   104G  14.0G  /
tank/gentoo/src                1.26G   104G  1.26G  /usr/src
tank/swap                      4.25G   107G  1.29G  -
```


----------



## SirDice (Aug 12, 2016)

The mountpoint may have been set but this doesn't mean it's actually mounted. What's mounted set to and what does mount(8) say?


----------



## Kajanos (Aug 12, 2016)

SirDice said:


> The mountpoint may have been set but this doesn't mean it's actually mounted. What's mounted set to and what does mount(8) say?



Was not mounted. Close discussions.


----------



## coolhandluke (Aug 13, 2016)

Kajanos said:


> Was not mounted.



What about after a `reboot`?


----------



## Kajanos (Aug 13, 2016)

coolhandluke said:


> What about after a `reboot`?


ZFS wants to mount. We must change mountpoint after recv if we have another pool on the system and lloks fine.


----------

