Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ZFS datasets mounted to incorrect location #453

Open
johnramsden opened this issue Dec 23, 2017 · 9 comments
Open

ZFS datasets mounted to incorrect location #453

johnramsden opened this issue Dec 23, 2017 · 9 comments
Milestone

Comments

@johnramsden
Copy link

@johnramsden johnramsden commented Dec 23, 2017

When I set up jailed datasets on FreeNAS, and mount the jail data sets inside of my created jail, I'm able to create and manage them, but they are mounted to the wrong location. For whatever reason they are being mounted with a parent /mnt directory. I have not experienced this behavior when using Iocage cage on regular FreeBSD.

  • iocage --version: Version 0.9.10 RC

  • Output from the commands issued:

Outside jail:

[root@host]#  iocage set jail_zfs=on jail_zfs_dataset=data/unifi jail_zfs_mountpoint='none' unifi
Property: jail_zfs has been updated to on    
Property: jail_zfs_dataset has been updated to data/unifi                                  
Property: jail_zfs_mountpoint has been updated to none

Inside jail:

[root@unifi]#  zfs create -o mountpoint=/usr/local/share/java/unifi tank/data/unifi/data
[root@unifi]#  zfs mount                                                                   
tank/iocage/jails/unifi/root    /                                                          
tank/data/unifi/data            /mnt/usr/local/share/java/unifi
  • Expected output

I would have expected my data set to be mounted to the location specified by the mountpoint property inside of the jail.

@skarekrow
Copy link
Member

@skarekrow skarekrow commented Dec 25, 2017

This is because FreeNAS uses an altroot for the zpool import. So that will always be prepended.

@skarekrow skarekrow closed this Dec 25, 2017
@johnramsden
Copy link
Author

@johnramsden johnramsden commented Dec 26, 2017

@skarekrow That puts the datasets in the wrong place inside the jail though. Is there a workaround to put the datasets in the correct place?

@skarekrow
Copy link
Member

@skarekrow skarekrow commented Dec 26, 2017

I'll peek to see if there's anything we can do , but I don't think there is :(

@skarekrow skarekrow reopened this Dec 26, 2017
@johnramsden
Copy link
Author

@johnramsden johnramsden commented Dec 27, 2017

@skarekrow That would be great. nullfs mounts for now I guess.

@skarekrow
Copy link
Member

@skarekrow skarekrow commented Jan 11, 2018

I cannot find a way to not apply the altroot to a jailed dataset with zfs. I'll keep this open for a little bit to see if I can poke some people who might have an idea.

@drphilth
Copy link

@drphilth drphilth commented Apr 12, 2018

Just a note that this breaks poudriere in a jail on FreeNAS - poudriere is able to successfully create a zfs dataset but it ends up mounted in an unexpected location (extra /mnt/ prepended) so the tool fails.

@vongrippen
Copy link

@vongrippen vongrippen commented Jul 2, 2018

A workaround that I've been using for this is to export, then reimport my zpool without the altroot. It doesn't seem to cause any issues with FreeNAS (provided you don't have any datasets with mountpoints that overlap the system) and solves my poudriere problems.

All it takes is:
zpool export tank
zpool import tank

@gronke gronke added this to the 1.1 milestone Oct 3, 2018
@ohmantics
Copy link

@ohmantics ohmantics commented Nov 13, 2020

This is still a problem with FreeNAS 11.3-U5.

@sonicaj
Copy link
Member

@sonicaj sonicaj commented Nov 13, 2020

@ohmantics can you please create an issue at https://jira.ixsystems.com ? And please attach a debug of the system as well ( System -> Advanced ). Thank you

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
7 participants