So… I dont know where to start actually…
Thing is… Scale now supports docker. So what i did was i installed nextcloud AIO and some other Containers.
Then i wanted to make a rsync backup so i looked up where my data actually gets stored. After a quick Google-Search : /mnt/.ix-apps/docker
Problem now is : Rsync wants that i select a path on a pool.
Meaning Docker is saving everything to my boot pool.
Is this how its meant to be? If not… how can i let docker and other apps be stored on some Diskpool?
UPDATE : We now vaildated that Truenas does save Dockerfiles on a Diskpool BUT IT DOENST TREAT IT THAT WAY.
Dockerfiles have a seprate path for some reason.
its /mnt/.ix-apps/ AND NOT /mnt/diskpool1/.ix-apps/ (what should be the case)
Because of that, rsync for example wont work
Okay the story goes on…
As we discoverd… my files are under /mnt/.xi-apps/docker
a path on my bootpool.
The Problem here is… the Docker Folder is 200gb large…
My Bootdisk is just 100gb large…
WHERE IS MY DATA STORED?
I guess your right. My Data does get stored on my ssdpool1 else it wouldnt even fit. There is no VDEV or something…
How can i solve my rsync problem like that?
[EINVAL] rsync_task_update.path: The path must reside within a pool mount point
One useful tool I found to navigate is the “mc” command, make sure you use “sudo mc” if you are trying to move container information - wouldn’t let me otherwise:
Yeah… as you can see… all my pools and the… ix apps thing.
Problem is… Truenas saves my data on ssdpool1 but the path is /mnt/ix-apps/docker AND NOT /mnt/ssdpool1/ix-apps/docker/
There is NOTHING about my Docker-Apps.
xi-applications is predocker eara / old kubernetes and not longer in use.
and Nextcloud i created on my own for a SMB share.
Here the Proof that i have Apps installed and ive choosen ssdpool1
I have a lot more containers but the containers i installed per Portainer arent shown.
cc @kris as this is quite an important use-case, and users should absolutely be able to rsync their app config.
Seems like some oversight in src/middlewared/middlewared/validators.py as this will be raised if /mnt/<vol_name> is not matched, which doesn’t include /mnt/.ix-apps
src/middlewared/middlewared/validators.py
vol_paths = [os.path.join("/mnt", vol_name) for vol_name in vol_names]
if not path.startswith("/mnt/") or not any(
os.path.commonpath([parent]) == os.path.commonpath([parent, rp]) for parent in vol_paths
):
src/middlewared/middlewared/async_validators.py
vol_names = [vol["vol_name"] for vol in await middleware.call("datastore.query", "storage.volume")]
Yes. Sorry for the confusion.
The main problem i try to explain here is…
Truenas treats dockerdata as somewhat of its own pool.
under the WebUI > Dataset for exmaple. There is no track of my Dockerfiles.
and under /mnt/ where only my Diskpools should be… there is also .ix-apps hidden. But its not a Pool in it self.
BUT IN THE WEBUI UNDER APPS
you set your diskpool for your apps.
If you then go into your console and go to /mnt/youdiskpool/ theres no dockerdata to be seen. They just exist in /mnt/.ix-apps/
Thanks for submitting a NAS ticket. The hiding of ix-apps is a design decision, but there may have been an oversight in terms of rsync compatibility.
I’m wondering if you could approach this differently though by using the actual location of the hidden dataset rather than the mount point. You can run df -h /mnt/.ix-apps to see the actual path to the dataset on your pool. Then try manually typing that path into an rsync task. I don’t have a remote system ready to go at the moment, but I did a quick test of this and it at least doesn’t raise any validation error.
Out of curiosity, do you remember what your search term in Google was and what kind of results it showed you? I’d be interested to know if our documented explanation of the ix-apps dataset doesn’t appear in search results.
This was my point in raising the ticket, it looks to be an unintentional regression from 24.04, where the design choice has hindered functionality that was originally in place with the exposed ix-applications dataset (at least to my knowledge).
Unfortunately it looks like it’s been closed without changes shortly after I raised it due to me ‘misunderstanding’.
“This is by design and is not an oversight. You’re misunderstanding the fact that /mnt/.ix-apps is a mount point. Not a filesystem. The ix-apps dataset exist on any given pool (depending on which one you’ve configured).”
(I actually have no idea what was meant by this considering I’m aware of the fact that /mnt/.ix-apps is a mountpoint…)
Are we seeing different things here?
root@truenas[~]# df -h /mnt/.ix-apps
Filesystem Size Used Avail Use% Mounted on
nvme/ix-apps 773G 256K 773G 1% /mnt/.ix-apps
Error: rsync: [sender] change_dir "/mnt/nvme/ix-apps" failed: No such file or directory (2)
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1338) [sender=3.2.7]
Error: rsync: [sender] change_dir "/mnt/nvme/.ix-apps" failed: No such file or directory (2)
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1338) [sender=3.2.7]
And of course trying with /mnt/.ix-apps, or anything that does not start with /mnt/ fails with: [EINVAL] rsync_task_update.path: The path must reside within a pool mount point
