With a forum search I only found threads in the archived forum, nothing in the new forum.
I would like to have no data on my macOS, meaning I would like to have all data in TrueNAS. My macOS installation should be as “stateless” as possible. What is the best way to do this?
Have you realized something like this? What exactly does it look like? Or are you all Linux users and don’t use macOS?
Apple used to officially support diskless workstations and network home directories — whether fully remote or locally cached/synced. There were always some quirks and complications, particularly with third-party applications. But with persistence and folk wisdom you could keep up a lab that way.
Then they discontinued Mac OS X Server, and basically stopped QA on this. So I’d imagine that the caveats and paper cuts have been piling up for a number of years.
Apple still offers some documentation on the basics, but then it also still mentions AFP. So you can imagine how long it’s been since that was last vetted.
What’s your primary motivation: is it about self-healing storage, or is your daily working set larger than makes sense for the sizes/prices of internal SSD?
I’ve started to explore using TrueNAS as a DAS, lately. Specifically for Mac-native workloads that aren’t supported or safe over SMB or NFS.
It depends on the version of macOS. I was able to do this with older macOS releases (High Sierra and earlier).
With the current release (Sequoia) I tried moving my home directory to a locally attached SSD with APFS and that only sort-of worked. Apple is doing some things in terms of security under the covers that are very strong and helpful to the vast majority of users. Unfortunately, they prevent us from tinkering too much with the OS and configurations.
So I do not think you will be able to do this with any modern release of macOS.
You could use something like NextCloud to sync your home directory, but I suspect that will not be a full recovery solution. I have been using Time Machine to backup my Macs and have been very happy with it.
P.S. I bought a MacOSX Mini Server back in the day. It came with 10.6.8 (Snow Leopard) Server and it worked great. Unfortunately, that was the last time Apple released a fully featured server version of MacOSX / macOS, since then Server has been an add-on application from the App Store and with each release it has had less functionality. I have not touched it in 4 or 5 OS releases.
I’m a macOS user, Seqouia latest version, with a Mac mini M4 and because the internal disk size is small, I purchased a thunderbolt 4 dock and installed a 1TB NVME SSD on it. I’ve mounted the APFS formatted SSD on /Volumes/home and moved my home directory there. I use this as my daily driver and I don’t have any issues with it. What do you mean @PK1048 that it sorta works? I had to tweak some permissions but my setup is fully functional.
She could probably use either SMB or NFS from her TrueNAS and do the same. I know that both work with macOS Sequoia as I’ve used NFS and SMB on my Mac mini. With that said, I have not used either SMB or NFS on macOS for home directories just for mounting file shares from TrueNAS.
But, she might run into issues with some Applications using a non APFS volume. For example, I have some numbers spreadsheets stored on an SMB volume that I mount and when I close the Numbers app, I always get a warning that the volume “does not support permanent version storage”. So, while you could get SMB or NFS to work, you might run into issues with Applications that make use of extended APFS things.
I had the same issue except with a MacBookPro M1 with only 500 GB SSD. I used an external 1 TB USB-3 SSD and did similar pointing at the mounted volume for my home directories. The biggest issue, but not the only one, was that neither iCloud nor OneDrive would sync from the ‘removeable’ drive. Maybe if I had used TB and not USB it would have been different. I even opened a ticket with MS and was informed that OneDrive would only sync with internal drives. Internal drives do have additional security information embedded on them that makes the mac useless without an admin account (great for theft remediation). This was about 2 years ago and I do not recall the other issues, but OneDrive sync was the biggest as it also effected the ability to save directly to the cloud from Office applications.
I do use SMB (and before that AFP and NFS) for data storage and am very used to the warning about a volume not supporting revision control. I get that warning from most well written macOS applications, such as OmniGraffle, Pages, Numbers, etc.
Ahh, I do not use OneDrive or MS apps. I do know there was an issue in Sequoia 15.1 with using an external disk for home directories but that got fixed in 15.2 and I have no issues at all on my Mac mini and with the TB dock, I get over 3000 MB/s read/writes.
@Olivia you could auto mount an SMB or NFS share in macOS. For home directories, I’ve always used NFS on Linux or FreeBSD machines. You would have to synchronize your UID and GID on all 3 machines, TrueNAS, Linux, and macOS to be the same or possibly use the “mapall” option on your TrueNAS NFS share. On macOS to reliably mount an NFS share, the directory would best be at /usr/local. You would need to “mkdir /usr/local/home” and change its ownership. So given that you have an NFS share on your NAS at 192.168.1.100 for example and the share is /mnt/zvol/home/, this /etc/fstab on your macOS would auto mount the share when your Mac boots:
Then I can update Files on Linux, and macOS sees the changes immediately. Then the NextCloud sync client does all the hard work. Does anyone have more experience with this?
There is some latency before NextCloud syncs, but it is on the order of seconds for small files.
I went back and re-read your specific use case, you want your mac’s to effectively be field replaceable units with no data on them. I achieve this through a combination of Time Machine (to backup my account configuration) and having a file server where I put all my data. I used to use NFS and then moved to AFP when the Apple NFS client was so slow, and now I have moved to SMB.
Are you using more than one Mac?
Are they running the same version of macOS?
If you sync home directories, I have seen macOS get very angry, especially if there are different versions of macOS as the newer will keep trying to upgrade the data it finds (especially under $HOME/Library). I have also seen two Macs of the same version fight over some file or another leading to corruption of data. I believe that macOS assumes it has exclusive access to $HOME.
I got email notification of a reply which does not appear on the forum. There seemed to have been several forum anomalies that evening.
If you don’t mind my paraphrasing your answers to my question: I think you indicated that you have limited space on your Mac’s SSD; you use a USB drive to supplement there; and you’d like for both your Mac and your Linux desktops to have ready access to each other’s data at all times.
This all sounds sensible to me — to a point. The USB drive does not provide ZFS-grade data safety, and probably doesn’t provide enough space, either. So moving that data to TrueNAS sounds like a wise priority. And being able to share it with Linux: yes yes yes!
But I don’t see any reason for you to move your home directory out from under macOS on the internal SSD. Decoupling those hardware-integrated protections would unnecessarily complicate the system, affecting reliability and security.
Neither machine is netbooted; neither is diskless. I would encourage you to keep a Mac-native Mac desktop environment on one machine, and a Linux-native Linux desktop environment on the other.
Have them share access to a massive shared dataset or three, but don’t let them step on each other’s infrastructure.
I humbly suggest that the conversation we should be having is about automounting shares, and not about network home directories or remote-managed accounts.
This is generally the approach I took back in sysadmin days. This simplified version is:
automount NAS storage at known local paths on user login (on client system)
use backup software to generate backups of user profiles (with specific retention period) to the NAS.
have IT / HR policy in place that dictates users not use local storage for files
(1) generally works, (2) gives a chance to recover if someone is storing stuff locally and makes a mistake, and (3) encourages (1).
I generally found roaming profiles (which is how this works in Windows) to be more of an admin headache. It also offers the option for workers to use local storage on client system in case of NAS production outage. This of course isn’t the only way to solve these sorts of issues, as an admin you have to look at what your various risks are and decide what course of action minimizes the ones you care most about.
Local Home Directory: lived on the Mac even when signed into common resources. This was the fastest, and by far the best-supported option.
Network Home Directory: very common on NextStep, using NFSv3 (at a time when their native local filesystem was UFS). Apple experimented with extending this feature to AFP, and to NFSv4, and to SMB… but too much software (notably Adobe’s) showed persistent incompatibilities. Changing protocols only seemed to move the symptoms around.
Portable Home Directory: would sync to local storage at login and logout — as they do today for school-managed fleets of iPads. I assume they were chasing some important feature of Windows Server. This reduced third-party incompatibilities, but not by as much as it increased day-to-day flakiness.
Nearly everything has changed since then. I wouldn’t try to outsmart the firmware’s integration with APFS and FileVault and key management, etc. without extremely good reason and a well-reviewed plan.
This was standard on almost all legacy commercial Unix systems; Sun’s SunOS/Solaris, IBM’s AIX, HP’s HP/UX, SGI’s Irix, I know I am missing more…
Linux’s default is local home directories largely because Linux was not used in large environments of tens, hundreds, or thousands of workstations and users sharing data from servers. Linux was used by individuals, so the concept of a shared home directory (one stored on a server and mounted to every workstation (and server) the user may log into) was foreign to many them.
Meanwhile Mac filesystem APIs describe relative operations on the equivalent of inodes, rather than on paths. (Also yes resource forks and metadata… but we understate the impedance mismatch between paths and specs/refs — and the loss of universal locking semantics.)
So Mac-derived code was usually good with AFP, and NeXT-derived code was usually good with NFS. All Mac apps are a mixture of the two, so there’s some friction for everyone moving Mac home directories onto any network shares supported by TrueNAS.
Not many developers support this in QA; not many audiences pressure them to.