Plugin script may miss to use absolute path leading to create warden folder into wrong path

[iXô]

Hello, I am quite new to FreeNAS (and even *BSD), but I think I found a little bug.

First I am describing my configuration :

- Boot system as ZFS with 2 Micro SD Flash drives
- Main ZFS volume as Raid Z2 with 6 T0 drives (named zfstemp)
- Jails root as /mnt/zfstemp/jailsroot

For the moment I've only used the Web GUI.

Because I needed to check permissions for a jail, I went using the console tool from the web gui.

Then here is was I descovered :

- normal volume and everything under it :

[root@freenas /mnt/zfztemp]# ll
total 77
drwxr-xr-x 6 root wheel uarch 6 Jul 26 11:00 ./
drwxr-xr-x 4 root wheel uarch 120 Jul 26 01:06 ../
drwxrwxr-x 3 root wheel uarch 3 Jul 24 21:33 home/
drwxr-xr-x 24 root wheel uarch 24 Jul 26 02:25 jailsroot/
drwxr-xr-x 3 root wheel uarch 3 Jul 26 11:01 temp/

As you can see no problem so far.

But if I do the same thing I folder backward :

[root@freenas /mnt]# ll
total 28
drwxr-xr-x 4 root wheel uarch 120 Jul 26 01:06 ./
drwxr-xr-x 19 root wheel uarch 27 Jul 25 15:14 ../
-rw-r--r-- 1 root wheel uarch 5 Jul 24 20:11 md_size
drwxr-xr-x 3 root wheel - 40 Jul 26 02:16 mnt/
drwxr-xr-x 6 root wheel uarch 6 Jul 26 11:00 zfztemp/

Extra mnt folder here... strange, looking into it :

[root@freenas /mnt/mnt]# ll
total 24
drwxr-xr-x 3 root wheel - 40 Jul 26 02:16 ./
drwxr-xr-x 4 root wheel uarch 120 Jul 26 01:06 ../
drwxr-xr-x 3 root wheel - 40 Jul 26 11:11 zfztemp/

In fact, the zfstemp here contains a jailsroot folder, and this folder content makes me guess that a script somewhere have a problem. I think the script may be responsible for init a jail because of the content :

[root@freenas /mnt/mnt/zfztemp/jailsroot]# ll
total 82
drwxr-xr-x 4 root wheel - 80 Jul 26 11:11 ./
drwxr-xr-x 3 root wheel - 40 Jul 26 11:11 ../
drwxr-xr-x 8 root wheel uarch 8 Jul 26 11:13 .warden-template-pluginjail--x64-20150726010623/
drwxr-xr-x 9 root wheel uarch 10 Jul 26 11:13 .warden-template-standard--x64/

If I am not wrong, theses datas are not into my zfs volume, but on my boot volume.

What I don't understand is how theses data can be created as the boot volume is mounted read only ?


I wanted to work around this problem by creating a simlink like that : /mnt/mnt -> /mnt

But, so far, I can only go this far :

cd /mnt
mv mnt mnt.temp
ln -s /mnt/ /mnt/mnt

Then I am unable to move datas :

[root@freenas /mnt/mnt]# mv /mnt/mnt.temp/zfztemp/jailsroot/.warden-template-* /mnt/zfztem
p/jailsroot/
mv: rmdir /mnt/zfztemp/jailsroot/.warden-template-pluginjail--x64-20150726010623
: Directory not empty
mv: rmdir /mnt/zfztemp/jailsroot/.warden-template-standard--x64: Directory not e
mpty

Do I have to open a ticket ?

And how can I work around this problem ?


Thanks.
Best regards.

 

[Nucshuco]

I am also seeing the /mnt/mnt after installing pluginjail and standard.
X10SRL-F
Processor: Intel(R) Xeon(R) CPU E5-2630 v3 @ 2.40GHz
32GB ECC DDR4 2133MHz
8x4 WD Reds RAIDZ2
32GB SATA DOM

 

[iXô]

After some tests, the warden plugin dataset was for the plugin xdm, and the warden standard dataset was for 2 standard jails.

After deleting jails and plugin, and using zfs destroy -R ... to remove theses folder, using the self symlink trick seems to be a good workaround.

As I am not the only one affected by this strange bug, I will create a bug report.

 

[iXô]

Created bug report : https://bugs.freenas.org/issues/10738

 

[iXô]

Ok, seems to be already reported : https://bugs.freenas.org/issues/10408

 

[iXô]

For people that know how to use vi, the problem can be solved by applying this commit : https://github.com/freenas/freenas/commit/5c49283d1874090324c12ff47e8a8f23882d02f9

 

[cyberjock]

This problem has plagued me for quite some time. I haven't had a pressing need for a new jail, but I knew I couldn't create new ones because of that bug. Glad to see it is fixed.