Does this replication process create a snapshot, if one doesn’t exist, which is then replicated to newpool?
In my instance on TN1, I see:
# sudo zfs list -t snapshot ssd/ix-apps
NAME USED AVAIL REFER MOUNTPOINT
ssd/ix-apps@auto-2025-01-22_20-05 64K - 120K -
That’s several weeks old snapshot that’s being replicated, and thus newpool/ix-apps only contains data from that point in time, without the recent additions/changes.
I have a separate instance TN2, which didn’t appear to have a pre-existing snapshot and copied over all current data based on today’s snapshot.
# sudo zfs list -t snapshot ssd/ix-apps
NAME USED AVAIL REFER MOUNTPOINT
ssd/ix-apps@auto-2025-03-10_22-18 0B - 124K -
In the Replication Task Wizard GUI, it actually specifically says:
0 snapshots found. Snapshots will be created automatically.
Seems that as a one-time process taking place sequentially, these steps are great. If someone were to start this migration process, replicate the ix-apps dataset, as a dry run, for example, and then want to run it again at a later time, it would not create a new snapshot and merely replicate the first created snapshot that’s potentially missing apps/containers or changed data. Buyer beware.
In my case, I destroyed the existing snapshot from prior attempts and then rerun the wizard.
One part that I misunderstood was that I thought you did this by choice rather than necessity. Or that’s what I think now.
I tried to use the GUI and click through to set the source and destination which didn’t show any oldpool/ix-apps or newpool-ix-apps folders so I went and replicated oldpool/ix-applications.
Maybe you could clarify in the post that typing the paths is required? thanks!
I’ve managed to migrate to another pool, and apps are running from there now, however I’ve noticed that under Datasets, it’s still saying that my original pool has the Apps role.
I was originally on Core, had an SMB share and plugins all on the same pool.
After migrating to Dragonfish, I recreated the apps. But then found my SMB share wouldn’t work on the folder that contains Apps because, in Egon’s layman’s terms for why you don’t cross the streams: It would be bad.
Updated to Electric Eel and then Fangtooth, where they changed from K8 to Docker.
After looking into it a little, my understanding is that the folder for apps was changed from ix-applications to ix-apps. I still have an ix-applications folder on my original pool, and if I try to enable my original SMB share, it comes back with a lot of ACL errors around that ix-applications folder.
Would that potentially be why my original pool is still showing as being the one with the Apps Role? Do I need to migrate the ix-applications folder as well, or is that legacy K8 stuff and can be removed?
One other thing that I haven’t done is remove the ix-apps folder from the original pool. I did update the mountpoint and select the new pool for apps after. Have even tried rebooting, but still no dice.
I don’t have much actual experience with the scenario you have
are you sharing via SMB the root dataset of a pool?
you can delete the ix-applications dataset after you have migrated to ix-apps
you should be able to delete the ix-apps dataset on the original pool, once you have migrated it to another pool
I’m not 100% certain how TrueNAS determines that a pool has the apps role, it could be because the ix-apps dataset is present. You could try renaming it to see if that is the cause.
Yep. Bit of a no-no, I know, but this is just for personal use, so I don’t mind. I created this back in my young and reckless days haha.
Interestingly, I went to do a zfs destroy -r LockieNAS/ix-apps and got the following:
root@freenas[/mnt]# zfs destroy -r LockieNAS/ix-apps
cannot destroy ‘LockieNAS/ix-apps’: filesystem has dependent clones
use ‘-R’ to destroy the following datasets:
LockieNAS/ix-applications/releases//volumes/ix_volumes/config
LockieNAS/ix-applications/releases//volumes/ix_volumes/config
LockieNAS/ix-applications/releases//volumes/ix_volumes/config
LockieNAS/ix-applications/releases//volumes/ix_volumes/config
LockieNAS/ix-applications/releases//volumes/ix_volumes/data
LockieNAS/ix-applications/releases//volumes/ix_volumes/config
Tar’ed up ix-applications after deleting snapshots and manually removing left over snapshot files. Then tried to rm -R, but wouldn’t let me. Oh, thats right, its a dataset under the original pool haha. Deleted the dataset and the App role icon disappeared.
Tried to destroy ix-apps on the original pool and that worked.
Apps were still running, so I decided to unset the pool and reselect the new App pool. Except nothing showed up. All the apps were gone. After sweating for a bit, I gave the system a reboot, then all the apps were there again.
Interestingly enough, the App role appeared on the original pool again.
Now that the ix-applications folder was gone, I figured that my SMB share might work now. Sure enough, enabled and no errors. Accessible from my PC.
Oh well, it’s not a major having it show the apps role on the original pool, everything is working as intended.
Also all the apps are a LOT more responsive running on an SSD mirror vs my HDD storage pool!
Critical:
Replication “abc/ix-apps - def/ix-apps” failed: Destination dataset ‘def/ix-apps’ must be encrypted (as one of its ancestors is encrypted). Refusing to transfer unencrypted source dataset ‘abc/ix-apps’. Please, set up replication task
Is there any workaround for this?
All right, found a solution.
I went to apps > Choose Pool > newpool. This created the ix-apps structure in the new pool.
Then I went back to replication tasks, click edit on the failed one and selected “Replication from scratch”.
Save
Run job
At this point you can continue with original tutorial from Stux on step 7 (it is not necessary to update the mount point because it was updated here in step 1. when we created the structure through UI.
@Stux
I’m in a somewhat similar situation but also not really.
I had to destroy and rebuild my pool because of a disk error and the new drives were all smaller by 48GB so i couldn’t just replace the failed disk with a smaller drive.
I ran a replication task with recursive on and readonly off to an external hdd.
However for some reason just doing it recursively on the root of my pool it never replicated the /ix-apps/* data. I only have the “backup” of the previous system “ix-applications” on my external pool.
Not knowing this I’ve been struggling for days now with the zfs mappings and whatnot and nothing is working.
Everything looks correct, the mappings are there but they are not actually mapped.
For example I have config files in here:
/mnt/DupPool/ix-apps/app_mounts/adguard-home/conf/
but when i look at /mnt/.ix-apps/app_mounts/adguard-home/ there is nothing.
If i “trick” the system and copy the data manually into that mount point my adguard app runs and works so thats something at least.
But copying data into a mountpoint thats not actually mounted or linked is a recipe for disaster and I’m trying to figure out how to force unmount, delete all the potentially duplicated/wrong folders from the /mnt/ directory and then reboot to let it hopefully mount correctly. I just can’t get anything to work.
For example:
root@truenas[/]# zfs umount -f DupPool/ix-apps
cannot unmount ‘/mnt/.ix-apps/app_mounts/immich/video’: no such pool or dataset
root@truenas[/]# zfs set mountpoint=/.ix-apps DupPool/ix-apps
cannot unmount ‘/mnt/.ix-apps/app_mounts/immich/video’: no such pool or dataset
Any ideas please, I’m losing my mind and would love to not have to start from scratch again. Especially with years worth of photos in immich, it would take 5ever to save and import everything again.
Very interesting and usefull instruction, and with all contributions from others I’m sure I’ll manage over the weekend to act on my own TN instance. PCIe card and SSD are on their way so I can then move the apps to SSD (and away from main HDDs).
When looking into the root of my truenas I find 3 pools:
.ix-apps
DataTank (main HDDs)
NASBackUp (External USB HDD on which full backup resides)
Question: in the main pool I have shares defined for different apps such as nextcloud, File Browser etc. Do these shares also need to be moved to the SSD? Some of them?
Shares in pool DataTank:
/Applications
/Applications/FileBrowser
/Applications/FileBrowser/config
/Applications/Nextcloud
/Applications/Nextcloud/Appdata
/Applications/Nextcloud/PostgressData
/Applications/Nextcloud/UserData
/Applications/NGINX
/Applications/NGINX/certs
/Applications/NGINX/data
and then some actual SMB shares
pity. After succesfully replicating the pool to new pool I decided to delete the old .ix-apps folder: sudo rm -rf /mnt/.ix-apps > Errors as folder was occupied.
Okay, lets unset the apps pool again (which I already had set to the new pool, and confirmed apps were working), and try again. Success!
Set apps pool again, no apps installed…
I do have the pool /Apps but no folder /Apps/.ix-apps
Despite deleting the /mnt/.ix-apps it is again there (although empty)
No backups, as I made the educated guess it is not to much effort to recreate my Nextcloud and nginx instances. I was pondering on a fresh install anyway (and in the meantime first update to Fangtooth).
a small tidbit, As long as the pool isn’t raidz (so mirror or stripe), you can add your new devices as a separate vdev then remove the old vdev and it will effectively “shrink” the pool.
I’m assuming I can apply same process for ix-virt, it looks to be similar to ix-apps in the way it has a mountpoint under /mnt
I really wish ix would implement something semi-automated (the “system” dataset under advanced for instance, is a one-click move to a new pool from the GUI)
It does not seem to work for me it says /.ix-virt is not found. And the Instances now are broken because it detects that ix-virt was created originally in a different pool. Im kind of stuck
My copy from old pool (hdds) to new pool (ssds) went without issue per @Stux instructions. Thanks for that!
I’m running Truenas Version: 25.04.1
In the replication wizard, my replication found 14 “old” snapshots and I went ahead with the replication. After the replication finished, I noticed the data sizes don’t match, should they?
I was able to migrate my .ix-virt dataset with one minor complication:
the dataset was encrypted, and I couldn’t unlock it after receiving due to it being hidden from the datasets UI. I was able to resolve this by renaming it to something else, unlocking it, making it inherit encryption (of the pool), and renaming it back.
Interestingly the instances screen did know that it was locked and did offer to “Go To Dataset” but when clicked it would just take me to the dashboard.
