Hello Guys,
I’m in the process of creating the pool. I’m using Mac and wanted to ask what should be the best sharing type: NFS or SMB.
I’m aware that SMB is single threaded but not sure about NFS. Does NFS offers any extra benefits over SMB?
After retiring AFP Apple selected SMB for file sharing between Macs. Even Time Machine now works via SMB. I gues Apple didn’t put much effort into NFS over the time.
1 Like
SMB being single-threaded depends on the context. When you’re doing IO it will do AIO using multiple kernel threads via io_uring. When you’re doing something like a directory listing, for example that operation will be single-threaded (but I’m not sure if multithreading here would help that much). Samba generally has a “forking” process model. Each SMB session forks off a child process from the parent main smbd process. This means that two clients (Macs for example) don’t block each other in a single smbd process.
1 Like
Yes, the mantra is usually, NFS for linux clients, SMB for everything else. Because the protocol is so old and just about everything can use it.
But NFS is easier to config and faster for linux/unix clients. There are also Apple-specific extensions for SMB. Your setup, assuming your Mac is going to be the client, should be SMB (explore some advanced options to see any special flags).
I still don’t get how NFS is “easier”. For NFS you need to either set up an entire Kerberos infrastructure (which is a PITA) to get any kind of password auth and reliable uid ↔ uid mapping. Or you need to accept the share is open and need to somehow wrangle every client accessing it and the server itself to have matching UIDs (potentially having to recreate users, shuffle around groups, contend with missmatched defaults, etc).
Just so the permissions you set apply and applications don’t complain “Uh, I don’t own that file” even if though they actually do through serverside mappings.
With SMB the server just enforces permissions itself based on the username provided for the session and the client can just map users as it needs to without silly missmatches.
4 Likes
I’m currently running TrueNAS 26.0.0-BETA.1 and set the SMB service minimum protocol to use SMB3 with multichannel, Apple smb extensions and encryption required. SMB3 is not single threaded with multichannel enabled, see the Advanced options. I’m a Mac user as well. At some point when TrueNAS has the QUIC support for SMB3, I may setup Internet access to my share.
1 Like
I understand the forking thingy but any idea on the NFS side?
Is SMB3 available in BETA? I cannot see any such option in SCALE production release.
The Release notes says that BETA has Samba 4.23 and in the service settings you can set the minimum protocol version to SMB3 provided your client supports it. The SMB service Advanced settings is where you can require encryption and enable multichannel. multichannel is an SMB3 feature. I’m using it with my Mac’s.
1 Like
Hmm. I see. How do I know what version of SMB is supported on macOS?
macOS Tahoe supports SMB3, that’s what I’m using. macOS uses SMB3 as the default protocol since macOS 10.10
1 Like
It depends on what you are running, if Linux only go NFS, it is simple, Linux thing and no overhead like SMB.
I have NFS shares mounted on my Proxmox servers so the Debian LXCs can backup to it
.My Linux PC has NFS share so everything is saved into the NAS without depending on apps and what not.
I have only one share with SMB for my GrapheneOS phone.
The key to remember when dealing with NFS shares is the permission, always use group over user when granting access, remember the mapping option on TrueNAS and voila.
Windows???
With Linux is as simple as sudo mount -t nfs 10.19.0.12:/mnt/data/jellyfin /whatever/Jellyfin
Mapping is simple too, the catch is with Proxmox LXC containers which I do.
If the mapping on TrueNAS was set to root:media(media is a group used by the LXC container), on Proxmox mount folder I run a chown -R 10000:101000 folder and everything works like a charm within the LXC container, you never ever touch permissions from within the container.
10000 converts into root mapped within the container.
101000 converts into media mapped within the container where 1000 is the group GID.
Then chmod -R 2775 folder, that makes sure that any new file will always have root:media ownership.
mediagroup has radarr, jellyfin, jacket, qbittorrent, sonarr as member.
Only them and root can make changes.
Things get hairy if you start granting permission to users instead of a group, you are cooked, avoid it at all cost.
My Linux PC has a linux_group with my user in it, if I created another user named momi_v and add it as member to that group, you get access too without touching TrueNAS. That simple.
It has nothing to do with Windows. NFSv4 protocol requires Kerberos for user auth (yes, even on Linux). If you use NFSv3 or below, yes it is simpler, but there is no such auth and just straight up uid mapping, which is obviously insecure. File ACL’s also require NFSv4.
This is likely also the reason Apple decided to just default to SMB instead of NFS after they retired AFP.
1 Like
MacOS already had an NFS server / client at the time (still does). So doing something more clean-sheet with a well-defined protocol that has space in it for vendor-specific extensions to replace how they were using AFP makes sense (and supported authentication via a challenge-response protocol). Smaller blast-radius for existing (and future) users. Also opened up things for more cross-platform compatibility. So SMB here for apple made and still makes a lot more sense.
You might wanna check it again, the only information I found is that NFSv4 ….. can use…. Kerberos, not that it’s mandatory.
I cannot find that requirement anywhere.
My TrueNAS is only for me, no container and no exposure to the internet. I don’t need it to be like a bank.
No. KRB5 is the only real authentication (where real means authentication doesn’t depend on client basically saying “yo this is me” and the server basically trusting it).
2 Likes
Whatever AI is telling you that is obviously wrong as someone else already pointed out.