Can No Longer Write files to a NSF-mounted drive on one Server. Error -36

Question

Hi Folks:
I have searched the Net (including these forums now) for several hours and found nothing definite.
The story is this: I have a Fedora 14 server that, up to this point, has been acting as a file server. Sometime last week (around the 28th we think) it stopped allowing people to copy files from the Mac OS X 10.6.8 workstations (which is what we have, largely) to the shared drives. It fails with a "The Finder can't complete the operation because some data in "" can't be read or written. (Error Code -36)."  People can mount the drives in question, see them, read from them, copy from them, but not copy anything, or write anything (Save as from Word) to the drives.
Now at about the time period where this started we moved a mySQL database from this particular server somewhere else. As part of that operation, the server was rebooted. The server where we moved the DB to was not. It also have an NFS share that continues to work.
I have verified service by service that nothing is running that shouldn't be. One of my thoughts was that something came up that shouldn't of when the reboot happened. Everything seems fine in that regard.
My looking through the Net has yielded several possible answers none of which has worked. One has been that this is a sign of bad media.  I have checked the drive array in question three seperate times. It has passed all those times. I started another share on a separate spindle on the server and I still cannot write to this new share on a totally different drive.
The drives in question are formatted for EXT3 (hey, I've giving out as many details as I can here!  :-)  ).
I have also repaired permissions on the SOURCE drives. No luck there.
My export file looks like this:
/raid/data/BigBang 
*(rw,insecure,sync,no_subtree_check,nohide,all_squash)
/raid/data         
*(rw,insecure,sync,no_subtree_check,nohide,no_root_squash)
/raid              
*(rw,insecure,sync,no_subtree_check,nohide,no_root_squash)
/home/rkinne/test  
*(rw,insecure,sync,no_subtree_check,nohide,no_root_squash)
No thoughts on security right now. I'm trying to get this darn thing to work, especially on /raid/data/BigBang. That share WAS "no_root_squash" but I changed it to "all_squash" as I've been flailing around today. There was no change in behavior. The exports file on the other server that is working is virtually identical.
Two Mac workstations work right now. One is running 10.4. The other is running 10.7.3. The rest - the problematic ones - are running 10.6.8. One is running 10.5 and is also not working.
I have also flushed the DNS caches from the servers in question, but its too early to see if that will do something yet.
This issue has flumouxed folks for years now. I understand that. Oddly, it JUST came out of the blue for us.  Any thoughts would be appreciated.
Doc Kinne
American Assoc. of Variable Star Observers

Answer 1

TimVasilovic wrote:
I understand the process you are describing,  In the past I have been able to embed metadata to a Raw file, move it to a server, pick that file up on another computer and see the metadata without need of the .xmp sidecar.  Is the ability to embed no longer supported  by Photoshop? Since this issue began we have taken to doing all our metadata editing in PhotoMechanic, which embeds without creating a sidecar.  If Photoshop is pushing people to create sidecar .xmp files only for writing metadata to Raw files I will probabaly move fully to PhotoMechanic because using sidecars has proven tricky in the past with how our files get moved around.
If using Adobe Camera Raw on camera raw file you either have an XMP sidecar file created or the data is stored in a database.  Which happens it is your option in Edit/camera raw.  If you use ACR and edit a jpeg it does not create a distinct XMP file but it is also not directly written to the image either.  One can still delete the edits in Bridge with Edit/develp settings.
If you use a DNG the metadata is written to the image.  Not sure what process Photo Mechanic uses.
It appears to be a permission problem as other than CS6 Bridge is now 64 bit and has a new cache method there are no changes in how it handles metadata.