There are several ways to create sub-directories, but each method has its ups and downs, I believe or at least what I’ve noticed. The first one is through SSH. This is very simple. You basically login via SSH and create a directory using mkdir command. However, if you created a directory and the parent directory within /sharedfolders doesn’t exist yet, the directory is not going to be part of the MergerFS pool. Therefore, if you want this new directory to be part of the MergerFS, make sure to create the parent directory first on the web UI.
The -p switch will be used frequently in this post and here is the extract from the info and man pages.
## From the info page
‘-p’
‘--parents’
Make any missing parent directories for each argument, setting
their file permission bits to the umask modified by ‘u+wx’. Ignore
existing parent directories, and do not change their file
permission bits.
## From the man page
-p, --parents
no error if existing, make parent directories as needed
# The -p option would allows me to automatically create the parent directory if it doesn't exist # In this example, I didn't create the new_directory via the web UI. Therefore, I have to # use the -p option to automatically create the new_directory and the new_subdirectory mkdir -p /sharedfolders/new_directory/new_subdirectory/
About the above example, the directories new_directory and new_subdirectory have been created, but they are not part of the MergerFS pool. None of these directories will show up on the web UI. Therefore, it is not a good idea to create a parent directory via the CLI directly under /sharedfolders unless you have a reason to do so.
Now, if we created the sub-directories within /srv/hhhhhhhh-hhhh-hhhh-hhhh-hhhhhhhhhhhh/ using the mkdir -p option then the directory and the directories along the path will be part of the MergerFS pool. However, these directories are not going to show up in the web UI. The long string of “h” is the UUID of the MergerFS pool.
# The directories new_directory2 and new_subdirectory2 do not exist yet # The command "mkdir -p" will create these two directories mkdir -p /srv/13057169-23bc-4b5c-8f54-8929ef121939/new_directory2/new_subdirectory2
After creating the parent directory new_directory2 and the subdirectory new_subdirectory2, as mentioned earlier these will not show up in the web UI, so if you are planning to share these directories via NFS or SMB/CIFS using the web UI, they are not going to be available. You can still modify the /etc/exports for NFS shares and /etc/samba/smb.conf for SMB/CIFS. Modifying these files for shares is outside of the scope of this blog post.
The other way of creating a sub-directory is via the web UI. If the path doesn’t exist, the parent directories along the path will be automatically created and the entire path of directories will still be part of the MergerFS pool. However, the parent directories (path) will not exist in the /sharedfolders, but in /srv/hhhhhhhh-hhhh-hhhh-hhhh-hhhhhhhhhhhh/ which was created when we created the MergerFS pool from the previous post. Since the subdirectory was created via the web UI, it is going to be available for sharing via NFS or SMB/CIFS.
- Access Rights Management
- Shared Folders
- Shared Folders (tab)
- Give the folder a name
- Select the MergerFS pool that was created earlier from the Device drop-down menu
- Browse or type-in the path of the main directory in the Path field
- Click Save
- Click Apply
- Click Yes to confirm
- Shared Folders (tab)
- Shared Folders
- Repeat steps 1 through 5 for each sub-directory
If the parent directory has been created previously via the web UI, as shown in Figure 2, we can use this existing path to create a subdirectory as shown in Figure 3.
The end results are both the parent and child directories are going to show up on the web UI as shown in Figure 4, and both directories will be available if you desire to share these directories via NFS or SMB/CIFS.
About the files that are going to be on any of these folders, we will see the files exist on all of them that is because of MergerFS.
/sharedfolders//srv/hhhhhhhh-hhhh-hhhh-hhhh-hhhhhhhhhhhh//srv/dev-disk-by-label-LABEL
Even though it may look that the files have been duplicated on these locations, the inodes are all the same. I can safely say that the files you place in these directories, assuming that it is part of MergerFS pool, are not duplicated files. See Figure 5 for reference.
Knowing how the OpenMediaVault directory creation behaves, we can combine the two different methods and still get the benefits of the web UI easy sharing and MergerFS while taking advantage of the methods’ behavior.
Example scenario
Let’s say that we have a subfolder that we want to share publicly and we do not want a clatter on our web UI and don’t want anyone to accidentally deletes the parent directory from the web UI, but still, want this to be part of MergerFS pool. Since we know the behavior of this file system, we can leverage the CLI and the web UI to accomplish what we are trying to do in this example.
## Create a parent directory in /srv/hhhhhhhh-hhhh-hhhh-hhhh-hhhhhhhhhhhh/ ## The parent directory name is no_ui_pubic_dir ## Since we created the parent directory via CLI, this directory will not ## be visible in the web UI Shared Folder dashboard mkdir /srv/13057169-23bc-4b5c-8f54-8929ef121939/no_ui_public_dir
On the web UI, we will create a subdirectory named shared_public_dir under the parent directory named no_ui_public_dir. Make sure to append the subdirectory name after the parent directory in the Path field. If you notice in the background the parent directory no_ui_public_dir is not available, but it can be selected in the Path field. See Figure 6 for reference.
As shown in Figure 7, the no_ui_public_dir is not visible on the Shared Folder dashboard; therefore, we can not delete this parent directory via the web UI.
At this point, since the subdirectory is available in the web UI Shared Folder dashboard, this subdirectory can be shared via NFS or SMB/CIFS using the web UI. The parent directory will not. Obviously there are ACL, Privileges, etc, but that is another can worm to open.
Creating any directories via CLI will not be visible on the web UI Shared Folders, NFS and SMB/CIFS on the web UI dashboards. But there is an exception, the directory will be available in the Shared Folders when selecting the path. Understanding each method of how to create these directories and their behavior is going to be beneficial for the person who is administering an OMV server to better plan an action approach.
For me, I will try to stay with the web UI method because it really defeats the purpose of using the NAS distro if I were to use the CLI to do everything. Also, it would get so confusing down the road and I would need to figure out what I did and how I did it. Unless I have something I need to do via the CLI that I cannot do on the web UI, I will stick will web UI to keep things organize managing my NAS server. Otherwise, I would just spin up a Debian Linux and install SnapRAID, MergerFS, NFS and some other stuff.
I hope you will find this informative and if I need to make some corrections, please let me know.
Cheers!
Thank you so much!! This clarifies several things for me. I’m very new to OMV and know nothing about servers. I noticed that although there are lots of tutorials on installing OMV (especially on the Raspberry pi), there are fewer offerings on how to set up and use OMV.
Take care,