Hello, I am a basic user of Truenas looking for advice. I built a Freenas server in 2012 using AFP shares for time machine and our family photo library. Back then we used only mac. I haven’t really touched it except upgrading to Truenas. Now I would like to migrate all our shares to SMB as we have a mixture of osx, ios, android, windows devices. I would also like to swap out the 12 year old WD Red 3TB drives for new Seagate 4TB drives. They are set up in simple mirror raid. Truenas is installed on a sata SSD drive. I have 16GB ECC Ram, asroc board and intel pentium.
Any advice would be appreciated on how to do this safely. Thanks.
Create a backup of your data to an external drive.
Setup a new mirror pool (if desired) with the 4 TB drives.
Setup the datasets you need on the new pool. Create the smb shares.
Copy the data from the old to the new pool using the command line. I always use rsync in a tmux session for big copy operations. That never failed me.
Compare the source data with the new copy (bit by bit), at least for the most important folders/files. I’m on windows so I use winmerge for that. (<-- slow method but reliable)
It’s a lengthy process, a bit paranoid, given the ECC RAM and underlying ZFS filesystem but I think this way you can be 100% sure that your data was migrated successfully.
File names, permissions, and other metadata (like dates) are all stored in the file system, so you shouldn’t see any differences there. Obviously for permissions, you need to have the same user/group IDs.
Again: enable SMB on your existing data and go. That’s all you need to do. And if you’re using TrueNAS, you have to do it, because AFP is gone.
So I changed the share to an SMB and I am able to access it but now some of the folder names have changed to random characters. for example 2NKQVL~P is there any way to correct this? also I am not able to rename under my login but I am able to rename the folders under another users login. I do have a backup on an SSD connected to my mac.
I experienced your ‘2NKQVL~P’ name mangling issue on Scale. I don’t know your truenas version but I imagine the fix is similar. In your smb share Advanced settings, look for a setting like “Use Apple-style character encoding”, or “Apple Character Compatibility”, or something similar. If it’s greyed out, change Purpose to “No presets”, then enable the Apple-style character encoding. Don’t forget to hit Save. I had to stop and restart the smb service to make it take effect. That should fix it.
That’s a common issue moving from AFP to SMB, I dealt with that on core ages ago. I would also consider upgrading to 13.3 on core to help deal with any remaining fruit issues on SMB. That should help with Time Machine via SMB.
Found the setting and folder names are as they should be. Is there a scan tool I can use to find and correct these folder names so there are no future issues?
I discovered the issue while trying to run rsync based backups. The mangled file names resulted in files that could not be backed up (carbon copy cloner on macOS).
The likely reason being that the actual underlying file names (ie what Linux used at a file system level in /mnt/pool/dataset/folder/file) reflected the file name as saved when ACC was “on” while what the SMB daemon presented to MacOS was a mangled version thereof. The two didn’t match, therefore rsync couldn’t copy said files and/or folders.
Thus, I wonder if your household has MacOs and Linux users, whether turning on ACC for wider filename compatibility is a good default practice?
Presumably, there is a reason that ACC is turned off by default, ie less complexity re: keeping SMB happy or higher speed? Whatever the reason is, getting shares to allow ACC being turned on is more complex than it likely should be.
Given how common Linux and MaCS users are, it follows that ACC is likely a pretty common requirement. One shouldn’t have to know the secret handshake to enable ACC - ie changing the SMB share purpose from default to no presets and then enabling ACC hidden in advanced SMB share settings.
At the very least, the help overlay for ACC in the GUI should also alert the user re: how to enable ACC, not just warn users that its use carries risk. Graying it out without explanation just because the preset is wrong does not help the admin run their NAS.
I had a similar problem. I asked for explanation and documentation in a thread SMB mangles long file names to DOS8.3! Why? Have I fixed it? from August 2024. I got some replies from an iXsystems person who I believe is quite knowledgeable, but they did not really answer questions about what TrueNAS control exactly governs this behaviour.
This may be true for many TrueNAS systems, but I think it might be a bit of an oversimplification. It certainly is for me.
For Jonathan_Cerrone’s purposes, the TrueNAS file system is a backing store for two different server modules: Netatalk serving AFP, and Samba serving SMB. The client can present various filenames and filesystem features which the two server modules store differently on the backing store. If you have a backing store created by Netatalk for AFP purposes, and you have Samba start using it for SMB purposes, you might discover places where the TrueNAS filesystem usage differs.
One example which caused me trouble briefly was filenames involving quote marks, non-ASCII characters (e.g. Japanese) and the like. The TrueNAS admin UI for SMB shares has a checkbox, “Use Apple-style Character Encoding”, which might solve this problem, but it is poorly documented.
Another big problem for me is symbolic links. I use symbolic links extensively on my client computer. They link from one part of my project directories to another part. When I copy directory trees from my client computer to the TrueNAS server via AFP, Netatalk writes the symbolic links to the TrueNAS file system as symbolic links. Then when Netatalk presents those server-hosted symbolic links back to me via AFP, it presents them as symbolic links. But Samba software, and Apple’s client SMB software, do not currently support presenting symbolic links to clients. Instead, Samba presents the server file system’s symbolic links as copies of the directories linked to. That means my client-side tools which recursively search directories, but pass over symbolic links, get fooled into following infinite trails of apparent directories.
I understand why you say that. For some people, it is absolutely the right advice. For me, with my file names and symbolic link usage, it seems a little glib.
When using SMB service I noticed many folders were missing their contents. I have now disabled SMB and I am back to using my old AFP configuration. MOST folder contents is back but I am still missing the contents of 4 folders…which missed my last backup also. I would like to restore the contents of these 4 folders somehow. Any ideas?
