2 x WD Green 3D NAND (120GB, 2.5") - Boot drives (maybe mess around trying out the thread to put swap here too link).1 x ASUS Z10PA-D8 (LGA 2011-v3, Intel C612 PCH, ATX) - Dual socket MoBo.# Some Wi-Fi networks advertise faster speeds than the connected wired network.Īiming to mostly replicate the build from (with some mods, hopefully around about as good as that link) # To disable multichannel support completely uncomment the next line
# SMB configuration for macOS 11.3 Synology I also found the following macOS smb client settings to assist: Username map = /usr/local/etc/smbusername.map Nsupdate command = /usr/local/bin/samba-nsupdate -g Running testparm in the shell with the above produces: I'm wondering if there's enough interest in the TrueNAS community to warrant achieving a good set of configurations options for macOS clients through testing, with an idea towards establishing a recommended set of values that are considered "macOS advisable" for General file sharing and Large file sharing using Gigabit and 10Gigabit networks, so that people can build upon from there.
But I'm not sure how many are actually useful, deprecated or now even detrimental to performance.Īdditionally the vfs objects attributes is one area that I personally am still not really on top of and would like to explore further. I've read a lot of the SAMBA documentation in an effort to better understand these which has been invaluable. Vfs objects=fruit streams_xattr zfsacl catia ixnas preopen Regarding setting up SMB shares (being macOS's default protocol), I've seen many options listed all over the web such as:
#NETATALK MACOS CODE#
Here is the code in Netatalk that keeps the 'root' user from logging in for example: auth.Just wondering if anyone is willing to help identify a good/sound set of configuration options for a predominantly macOS client environment for TrueNAS on reasonably "okay/average" hardware that people may have lying around. feature-error.jpg for example)Ĭannot login as root to see the whole pi. (note, you can add a file to the pi's storage root and it shows up fine so you know it is working.
#NETATALK MACOS MAC#
Results in the folder disappearing from the π Tin volume aka root of the pi's boot volume you are looking at on your Mac desktop: (you may have to "disconnect" and "reconnect" from your Mac to see the changes faster)īut because you told the pi's file system to not allow "others" to "execute" aka display folder contents listing, you can't open it from your Mac regardless of the "read" setting on the folder.Īnd of course changing it back to allow "execute" hence get a folder contents listing: sudo chmod o+x /man Now, after executing the command line above and then opening the π Tin volume, you will magically see the "man" folder show up: That directory or "folder" should have shown under the π Tin volume with a whole bunch of others when you first opened it.but it didn't. Then for fun, set the "execute" bit off on the /man directory on your pi like this: sudo chmod o-x /man To the /etc/netatalk/fault file on your pi before the # End of File you will likely see a nearly empty volume = your when you open the π Tin volume from your Mac (aka file share, shared folder): Aggravating.įor example, if you tell Netatalk to share the root of the storage by adding: / "π Tin" If you do share the root of the storage system via Netatalk, and if your folder is at the root of the disk and if that folder permits the logged in Appletalk user to list it's content, Netatalk filters that folder out of the listing under the root of the storage aka "/". There is code in Netatalk that prevents the root user from logging in. You can't login as root user to see the entire contents of the pi's storage.