I can confirm that 2.1.01 added .DS_store files to the list of files to be rejected in smb.conf, which is not such a bad idea after all. I actually instruct Mac OS X specifically not to write .DS_store files to network drives!
For me, AFP is the more stable option in OS X. For some reason, the any share folders mounted in SMB will get unmounted after a while. This created a problem for me because i have automated jobs set up in Retrospect to backup to the N2100. I have no such problem using AFP.
The performance gain in the latest firmware (2.1.01) with AFP is quite significant for me. Write transfer rate goes from about 4 Mbyte/s to 10Mbyte/s , and read transfer rate goes from less than 8Mbyte/s to about 12 Mbyte/s.
The afp is using netatalk AFAIK and from past experience it's not the most efficient and stable piece of software (no offence to the developers).
Not to mention that for OS X users SMB performs better (faster and more stable) than AFP although many will likely dispute this. AFP is really just for those still running OS8 or OS9
I couldn't agree more with dbridges. What the n2100 is supporting is actually AFP over AppleTalk protocol, which is something we've all (Mac IT managers) stopped using years ago. The AppleTalk protocol is really outdated compared to TCP/IP, and tends to do "bad things" to networks that have TCP/IP traffic running on them.
If the n2100 supported the modern AFP over TCP/IP, then I think this would be a good option vs. SMB, but it does not. All modern Macs and Mac servers communicate using AFP over TCP/IP. The solution here is NOT to start turning on AppleTalk protocol on all the Mac clients out there (it's turned off by default on all modern Macs for a reason).
For now, the best solution for Mac users from a performance and network stability standpoint is to use SMB. Unfortunately, Thecus placed a lot of important hidden OS X files (like .DS_store) into the samba veto file. In order to use the n2100 with Mac SMB clients, we now have to edit the smb.conf file. How annoying.
Thecus: please make this a web menu option if some users want these files vetoed. Don't force us to hack the system just to get this basic functionality back.
By the way, I was also curious about the performance numbers. Here is a test I just ran copying a single large file up and down:
n2100 configured with two 300GB Seagate drives in RAID 1 Both tests on Gigabit link to Quad G5 running Mac OS 10.4.8:
AFP over AppleTalk: write: 6.2MB/s read: 22.7MB/s
SMB over TCP/IP: write: 6.7MB/s read: 23.5MB/s
Obviously using AFP over AppleTalk isn't much slower, but it's going to slow down the other TCP/IP traffic on your network (AppleTalk is very chatty).
Removing .DS_Store from the veto list worked although it took me a number of attempts to get the change to stick.
dbridges: I noticed there were a number of smb.conf files that all symbolically linked to: /raid/sys/smb.conf I am assuming this is the one you modified?
Also, did you remove all the veto files? Here is the list: veto files = /.AppleDB/.AppleDouble/.AppleDesktop/Network Trash Folder/TheFindByContentFolder/TheVolumeSettingsFolder/Temporary Items/.TemporaryItems/.DS_Store/.VolumeIcon.icns/.FBCIndex/.FBCLockFolder/
How has this modification been working for you? Can anyone with firmware 2.1.0 tell us what the "veto files" list looks like in their smb.conf file?
Other than these files appearing on Windows machines (cosmetic), can anyone give a good reason why these files should be deleted?
I would sugget Thecus to remove all the veto files in the next firmware release, because these files, such as .AppleDB and .DS_store, are created by Mac, and when Mac user sees these they should know these files were created by Mac.
If you hide these files under SMB, you still see these files in FTP. So, hiding them under SMB does not help FTP.
The symbolic linking of the files caused me a few issues.
Given my environment and to help me play i've got a hidden share to the root forder and i've been editing across the share with ultraedit.
Unfortunately the the edits's didn't stick unless i went in and edited it using vi. (I discovered last night that the only way to edit it to trace the symbolic links to the original file and edit that )
As for the veto list. I only removed the .DS_Store and everything has been working well with regards to the original issue.
What i also had to do afterwards was turn off map hidden and map archive because i didn't want any permissions issues when accessing the shares. (yes i know what i'm doing)