Small Dataset for Custom Scripts

[NASbox]

When UFS file systems were supported I used to keep my custom scripts on a UFS formated USB flash drive so that I had access to these scripts even if my storage pool was disconnected for some reason. Given how small the amount of data in /custom, I want to save it on the boot drive (a 100GB SSD). I do not plan to share /custom - it is only for use at the FreeNAS command line or with cron jobs.

How can I create a dataset called custom and have it automatically mounted under the root '/' as '/custom'?
(I would prefer a dataset over a simple directory because I can snapshot it for both protection and ease of backup.0

I tried creating the dataset using the information I found here:
https://www.freebsd.org/doc/handbook/zfs-quickstart.html using the following command:
freenas# zfs create freenas-boot/ROOT/customand got the following result:

Code:

NAME															USED AVAIL REFER MOUNTPOINT
freenas-boot/ROOT/custom										136K 103G 136K none

which is not mounted. What am I missing? What do I need to do to auto mount?

Will doing this damage the automatic updates? Is there any good reason not to do this?
(It's OK if the updates remove /custom just as long as the update works. I will back up /custom for easy restoration.)

 

[MrToddsFriends]

Do you have a special reason not to create a 2nd pool for this dataset using the FreeNAS GUI? As far as I can tell a dataset custom in a pool foo will be automounted to /mnt/foo/custom, so all you would have to do is to create a (edit: symbolic) link to /custom if you'd like to have such a link.

I do have a similar link, which is targeted to /root/althome and at least this did survive all updates so far.

 

[Chris Moore]

When UFS file systems were supported I used to keep my custom scripts on a UFS formated USB flash drive so that I had access to these scripts even if my storage pool was disconnected for some reason. Given how small the amount of data in /custom, I want to save it on the boot drive (a 100GB SSD). I do not plan to share /custom - it is only for use at the FreeNAS command line or with cron jobs.

How can I create a dataset called custom and have it automatically mounted under the root '/' as '/custom'?
(I would prefer a dataset over a simple directory because I can snapshot it for both protection and ease of backup.0

I tried creating the dataset using the information I found here:
https://www.freebsd.org/doc/handbook/zfs-quickstart.html using the following command:
freenas# zfs create freenas-boot/ROOT/customand got the following result:

Code:

NAME															USED AVAIL REFER MOUNTPOINT
freenas-boot/ROOT/custom										136K 103G 136K none

which is not mounted. What am I missing? What do I need to do to auto mount?

Will doing this damage the automatic updates? Is there any good reason not to do this?
(It's OK if the updates remove /custom just as long as the update works. I will back up /custom for easy restoration.)

I created a directory at ~/scripts
It's been working for me.

EDIT: By ~/scripts I am saying, /root/scripts and I have been using that for a couple years now with no problems, unless I have to do a full re-install because the boot media dies, but that only happened years ago when I was using USB sticks. I keep a backup of all my scripts in the main storage pool and I can just copy them back over if I do need a full re-install. Minor inconvenience.

 

[SweetAndLow]

Store them in /root if possible. That path will survive am upgrade all others will possibly be deleted.

 

[NASbox]

Thanks all for the replies...

Do you have a special reason not to create a 2nd pool for this dataset using the FreeNAS GUI? As far as I can tell a dataset custom in a pool foo will be automounted to /mnt/foo/custom, so all you would have to do is to create a (edit: symbolic) link to /custom if you'd like to have such a link.

I do have a similar link, which is targeted to /root/althome and at least this did survive all updates so far.

@MrToddsFriends my reason for not wanting to use a symlink the main pool is that I want the custom scripts to be available in the event the pool is disconnected. If I end up doing /root/custom, I may well create a symlink /custom - thanks for the suggestion.

I created a directory at ~/scripts
It's been working for me.

EDIT: By ~/scripts I am saying, /root/scripts and I have been using that for a couple years now with no problems, unless I have to do a full re-install because the boot media dies, but that only happened years ago when I was using USB sticks. I keep a backup of all my scripts in the main storage pool and I can just copy them back over if I do need a full re-install. Minor inconvenience.

@Chris Moore Thanks for coming back to edit... I was wondering what id ~ referred to. I may well go that way (and I will definitely back up to the main pool (and possibly my workstation as well) - I had scripts to backup and recreate the custom data from backup, so as you say it's no big deal as long as I have a backup.

Store them in /root if possible. That path will survive am upgrade all others will possibly be deleted.

@SweetAndLow thanks for confirming that... that may well be the best way to go

I was hoping to use a dataset so that I could use snapshots that are independent of any other dataset.

Other than having it wiped by an upgrade (I'm OK with that... I'll set things up assuming it is going to get wiped and then be happy if it's not.) am I likely to create any problems?

Can some tell me why the dataset I created with this command:
zfs create freenas-boot/ROOT/custom didn't mount?

A zfs list confirmed both the confirmation and lack of a mount point.

Code:

NAME															USED AVAIL REFER MOUNTPOINT
freenas-boot/ROOT/custom										136K 103G 136K none

Is what I want to do possible? If so, what am I missing?

Thanks again for the help.

 

[Chris Moore]

You could have just done cd ~ to put you in the root user's home directory and then done a mkdir scripts to make a directory.
Done.
There is no need to create a dataset or mount it. If you insist on having a dataset, which you will then have to set permissions on, you will need to manually set the mount point and it may not automount when the system is rebooted.
I wouldn't make a dataset, it is just an extra step that you don't need.

If you did want to mount the dataset you created, you would use a command like this (reformatted to represent your chosen names):
zfs set mountpoint=/mnt/Backup Backup

Then follow that up with a zpool export Backup

and a zpool import -a

ref: https://docs.oracle.com/cd/E19253-01/819-5461/gaztn/index.html

PS. I use a little rsync cron job to backup any changes I make in my scripts to the backup directory in my main pool.

 

[NASbox]

You could have just done cd ~ to put you in the root user's home directory and then done a mkdir scripts to make a directory.
Done.

Thanks for clarifying... I know what ~ is, but I wasn't sure if you were logged in as root in your example, or if you created some other special purpose id. I have a custom scripts directory on my pfSense box, but I don't run under root because of secruity considerations. My FreeNAS isn't directly exposed to the internet, so the risk isn't as great.

There is no need to create a dataset or mount it. If you insist on having a dataset, which you will then have to set permissions on, you will need to manually set the mount point and it may not automount when the system is rebooted.
I wouldn't make a dataset, it is just an extra step that you don't need.

If you did want to mount the dataset you created, you would use a command like this (reformatted to represent your chosen names):
zfs set mountpoint=/mnt/Backup Backup

Then follow that up with a zpool export Backup

and a zpool import -a

ref: https://docs.oracle.com/cd/E19253-01/819-5461/gaztn/index.html

PS. I use a little rsync cron job to backup any changes I make in my scripts to the backup directory in my main pool.

Thank you so much for taking the time to create such a detailed answer.

I was confused as to why when I created a dataset in one of my pools, it mounted and was available for use automatically, but a dataset created in freenas-boot freenas-boot/ROOT did not automount. I did a bit more reading and assumed it must have something to do with properties, and when I did zfs get all freenas-boot , I noticed:

Code:

NAME							PROPERTY			  VALUE				  SOURCE
freenas-boot					mounted			   no

which I should have noticed from the zfs list commands I have been runing all along. As soon as I did zfs create freenas-boot/ROOT/11.1-RELEASE/custom , the dataset /custom appeared and behaved as expected.

So when I do a zfs list, I now have:

Code:

NAME															USED  AVAIL  REFER  MOUNTPOINT
freenas-boot/ROOT											  3.94G   104G   136K  none
freenas-boot/ROOT/11.0-U3									   232K   104G   970M  /
freenas-boot/ROOT/11.0-U4									   248K   104G   973M  /
freenas-boot/ROOT/11.1-RELEASE								 3.94G   104G  1.08G  /
freenas-boot/ROOT/11.1-RELEASE/custom						   136K   104G   136K  /custom
freenas-boot/ROOT/Initial-Install								 8K   104G   980M  legacy
freenas-boot/ROOT/default									   232K   104G   980M  legacy
freenas-boot/grub											  7.82M   104G  7.82M  legacy

I'm confused as to why freenas-boot/ROOT is not mounted, but all the other update snapshots are mounted? Can someone please explain what is going on?

If I understand what is going on here, when I do an update, I am going to end up with

Code:

NAME															USED  AVAIL  REFER  MOUNTPOINT
freenas-boot/ROOT											  3.94G   104G   136K  none
freenas-boot/ROOT/11.0-U3									   232K   104G   970M  /
freenas-boot/ROOT/11.0-U4									   248K   104G   973M  /
freenas-boot/ROOT/11.1-RELEASE								 3.94G   104G  1.08G  /
freenas-boot/ROOT/11.X-XXXXXXX								 X.XXG   XXXG  X.XXG  /
freenas-boot/ROOT/11.1-RELEASE/custom						   136K   104G   136K  /custom
freenas-boot/ROOT/Initial-Install								 8K   104G   980M  legacy
freenas-boot/ROOT/default									   232K   104G   980M  legacy
freenas-boot/grub											  7.82M   104G  7.82M  legacy

Where freenas-boot/ROOT/11.X-XXXXXXX is the name of the update.

I would expect that under most circumstances /custom would still be on the disk and I could clone freenas-boot/ROOT/11.1-RELEASE/custom and zfs send | zfs recv it to freenas-boot/ROOT/11.X-XXXXXXX and /custom would be exactly as it was before the update. (It would likely be safer/easier to just keep a snapshot of /custom on the data pool and zfs send | zfs recv it to freenas-boot/ROOT/11.X-XXXXXXX, but I think there would be some built in protection even for a directory /root/scripts.

Is my thinking sound or am I missing something?

I don't have a setup for testing updates, but if someone sees this who is doing active testing could create a /custom dataset and let me know if it survives an update, it would be much appreciated-otherwise I guess I'll have to wait till the next update arrives.

As always, thanks so much for the input/advice.

 

[Chris Moore]

Thanks for clarifying... I know what ~ is, but I wasn't sure if you were logged in as root in your example, or if you created some other special purpose id. I have a custom scripts directory on my pfSense box, but I don't run under root because of secruity considerations. My FreeNAS isn't directly exposed to the internet, so the risk isn't as great.

The only things I go to the terminal for on FreeNAS need to be executed as root. I clarified because I realize that the ~ is the home directory for the current user, no matter what user you are logged in as, it doesn't automatically mean root.

Have a look at my list...

Code:

root@Emily-NAS:~ # zfs list
NAME															USED  AVAIL  REFER  MOUNTPOINT
Backup														 8.17T  4.59T   128K  /mnt/Backup
Backup/BigPond												 7.81T  4.59T  7.81T  /mnt/Backup/BigPond
Backup/Transfers												366G  4.59T   366G  /mnt/Backup/Transfers
Emily														  8.47T  12.6T  3.40M  /mnt/Emily
Emily/BigPond												  8.01T  12.6T  7.96T  /mnt/Emily/BigPond
Emily/Jails													 123G  12.6T   232K  /mnt/Emily/Jails
Emily/Jails/.warden-template-pluginjail-11.0-x64				678M  12.6T   678M  /mnt/Emily/Jails/.warden-template-pluginjail-11.0-x64
Emily/Jails/plexmediaserver_1								   123G  12.6T   123G  /mnt/Emily/Jails/plexmediaserver_1
Emily/Transfers												 344G  12.6T   344G  /mnt/Emily/Transfers
freenas-boot												   6.17G  29.9G	31K  none
freenas-boot/.system											125M  29.9G  2.56M  legacy
freenas-boot/.system/configs-7f5b34811f49423b82ac573d9dd30fdd  40.0M  29.9G  40.0M  legacy
freenas-boot/.system/cores									 31.2M  29.9G  31.2M  legacy
freenas-boot/.system/rrd-7f5b34811f49423b82ac573d9dd30fdd	  50.2M  29.9G  50.2M  legacy
freenas-boot/.system/samba4									 114K  29.9G   114K  legacy
freenas-boot/.system/syslog-7f5b34811f49423b82ac573d9dd30fdd	908K  29.9G   908K  legacy
freenas-boot/ROOT											  6.01G  29.9G	25K  none
freenas-boot/ROOT/11.0-U3									   164K  29.9G   726M  /
freenas-boot/ROOT/11.0-U4									   186K  29.9G   728M  /
freenas-boot/ROOT/11.1-RELEASE								 2.94G  29.9G   826M  /
freenas-boot/ROOT/9.10.1-U1									  43K  29.9G   638M  /
freenas-boot/ROOT/9.10.1-U2									  53K  29.9G   636M  /
freenas-boot/ROOT/9.10.1-U3									15.9M  29.9G   637M  /
freenas-boot/ROOT/9.10.1-U4									15.0M  29.9G   636M  /
freenas-boot/ROOT/9.10.2-U2									16.2M  29.9G   653M  /
freenas-boot/ROOT/9.10.2-U3									  63K  29.9G   653M  /
freenas-boot/ROOT/9.10.2-U5									3.02G  29.9G   655M  /
freenas-boot/ROOT/default-20170722-020143					   186K  29.9G   737M  legacy
freenas-boot/grub											  19.9M  29.9G  6.84M  legacy
root@Emily-NAS:~ #

These freenas-boot/ROOT entries are existing snapshots of the boot environment on the boot pool. When you upgrade to a new version, it creates a new dataset for the new install and mounts it at the system root. What is listed under the mountpoint column is where it would mount if it were mounted. The only one that is mounted is the one that is selected, normally the most recent, but you can roll back to any of your previous boot environments.

 

[NASbox]

These freenas-boot/ROOT entries are existing snapshots of the boot environment on the boot pool. When you upgrade to a new version, it creates a new dataset for the new install and mounts it at the system root. What is listed under the mountpoint column is where it would mount if it were mounted. The only one that is mounted is the one that is selected, normally the most recent, but you can roll back to any of your previous boot environments.

Thanks... I get it now, I should have looked at the other snapshots... I confused the presence of a mount point with actually being mounted.

Would I be correct in assuming you had changed something in /root/scripts while you were running freenas-boot/ROOT/9.10.1-U2 and you wanted to get a copy of the original file from freenas-boot/ROOT/9.10.1-U1 you could clone U1 and copy out the original files today while you are running 11.1?

Being able to get back your scripts directory even if the pool you backed it up to was offline for some reason would be really great.

Again, thanks for all your time... I really appreciate it.

 

[Chris Moore]

You could (through the command line) mount that dataset to a separate mount point somewhere on the system and access it just like any other directory. Then unmount it when you are done.