Casper Admin "Removing .DS_Store from the packages folder" errors during attempted replication...

[donmontalvo]

When we try to replicate to one (of many) Isilon shares, Casper Admin 8.64 sits there showing:

external image link

A peek at the Casper Admin log shows the error is continuous, with each error showing up 5-6 times, seems to be in some sort of loop:

external image link

The Packages folder only has PKG/DMG files in it...although non flat PKG files will have .DS_Store files in its' hierarchy.

This is only happening on one (of many) Isilon shares...has anyone seen this before?

TIA
Don

[AndyBeaver · Accepted solution]

I have ran into this problem as well, although it does not happen with any consistency. I usually just sudo rm /path/to/packages/.DS_Store as soon as that executes the replication finishes and doesn't seem to happen again for a while. Would love to know the root cause of the problem though

EDIT- for what its worth I have not seen this since upgrading to 8.71

[ImAMacGuy]

I just saw it today on 8.71 along with some M$ Office 2011 patches.

[donmontalvo]

@jwojda Thanks, it appears the error shows up before the actual replication starts. If Casper Admin can get past that error, replication is successful. We asked the Isilon team to remove .DS_Store so we can test replication again.

In the old days, Apple had a KB on how to prevent .DS_Store files from being created on remote volumes. They've archived the article for some reason (read: "We ain't supporting that anymore"). Unless there's another KB that I missed. :)

[rtrouton]

@donmontalvo,

Here's the defaults command:

defaults write com.apple.desktopservices DSDontWriteNetworkStores true

The KBase article is available here:

http://support.apple.com/kb/HT1629

[donmontalvo]

Yep, that's the KB that has been archived by Apple.

[rtrouton]

Right, but archived just means "We're not updating the article anymore". Not "this doesn't work."

This command is working just fine in 10.8.4. I've got it in my firstboot script:

https://github.com/rtrouton/rtrouton_scripts/blob/master/rtrouton_scripts/first_boot/10.8/first_boot...

[RobertHammen]

Even though the 8.71 update apparently didn't resolve the issue per @jwojda, I'd strongly suggest getting yourself updated to it (my guess is the last in the classic 8.x release chain). Fixed a TON of issues I was having (LDAP integration with AD, First Boot scripts not running, deploying CS5.5 from an SMB share using the .dmg/script) with 8.6.x...

[donmontalvo]

@rtrouton Agreed, however we would get confirmation from our Apple rep before hand. Articles are usually archived when they become irrelevant or unsupported. In this case we're wrestling with an issue that is likely Isilon related, as it only effects one of the many shares. So it's a piece of duct tape that we don't need to use right now. :)

[donmontalvo]

Well, as it turned out our storage team had to log on to the Isilon as root to get rid of the problem .DS_Store file. Once that was done, replication started, and completed without a glitch. So, not a Casper issue.

[scottb]

I'm fairly new to Casper, but the times I saw the .DS_Store files being created on the shares was when I was curious and made the mistake of browsing the CasperShare (SMB) volumes when mounted in the Finder.
I don't do that and also ran the command above (Apple) and things are fine. There's also a piece of software we use for other setups (video/audio) to keep the .DS_Store files from being created and it gives you much more control over that and other bits.
http://zeroonetwenty.com/blueharvest/

[donmontalvo]

I wouldn't worry too much about .DS_Store files being created on the server, not a fan of using duct tape, I'd rather get to the root of the problem and address it there. So we just need to be aware that if the above issue occurs, it may be due to a PKG/MPKG that Casper Admin is unable to delete (part of the replication process) due to a corrupt .DS_Store file.

Through trial and error, finding the effected PKG, and delete it, the problem problem should go away. The biggest PITA was that Isilon not only did not allow us to delete the .DS_Store file (even when logged on with the read-write account for the DP), the Isilon group needed to log on as root to delete the file. This is the only time we've ever run into this problem, hopefully this thread will help the next person. :)