OSX users avoid 2.1.01 (.DS_store issue)

[dbridges]

I upgraded to 2.1.01 the other day and started to move all of my files back last night.

Unfortunately something in the samba configuration has changed and the copy process generates an error when i try and copy the .DS_store file (Typically when copying it's containing folder)

As OSX is ruthless in littering filesystems with these files i rarely have a folder anyware on our network that doesn't have one in it.

Now that the thecus cant handle the file it's useless for backing up the MAC.

Is anyone able to post a generic (i.e. cut out your own details) config file for the samba settings for the previous firmware version.

[leyton01]

I don't know much about macs but can you use the AFP (appleshare?) protocol instead of smb?

[N2100Owner]

Are you trying to backup the MACs using SMB or AFP?
smb.conf's veto file contains .DS_store entry.
Using AFP should be OK.

[getmythe]

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!

[dbridges]

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

AFP is not the best solution because it means that i have to run two configurations, one for windows and one for OS X

And the n2100 isn't the gruntiest machine. I'm pretty sure that using AFP will kill any performance gain that the firmware provided.


Removing .DS_Store from the veto list worked although it took me a number of attempts to get the change to stick.


mini rant follows

I know that there are admins out there who are pedantic about these files but then admins never really have to use the systems they implement

The n2100 is billed as an easy to use cross platform device for home users and should perform like one.

If i wanted the perfect corporate NAS i'd have bought the N4100.

Thecus need to keep this in mind if they dont want large numbers of people returning their N2100's under warranty.

[ktulaman]

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.

[mk500]

dbridges said:

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).

[mk500]

dbridges said:

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?

[mwk]

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.

[dbridges]

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)