Hi all, I would really appreciate some help with this one if anyone has heard of this happening before. I have installed Samba on Ubuntu Server 8.04 LTS. There are two HDD's one large one for file storage which is mounted as a share. I have setup Samba to have "No authentication" which I believe forces everyone to user "nobody" and group "nogroup". I can see the share fine from my windows XP machine and can read and write to it. Everyone else in the office is on Mac's either OSX 10.4 or OSX 10.5. They can all see the share and read and write to it. server was cut over and went live with all data copied across last Thursday (5-03-09). Since then, two of the Mac OSX (10.5) clients are having a problem with InDesign CS. At least once a day, when they open an InDesign file (from the Samba share) and make changes to it, when they save the file it appears on all the mac clients on the network, as an alias instead of a file. It still has the .indd file extension but it is coloured orange and if any mac client tries to open it, they get an error message stating that the alias cant find the original file. If I browse to the location on my XP machine, I see the file as normal, and I can open the file no worries.If I right click on the file and choose 'properties', all is normal. I then have to copy it back to the original location with a changed file name and it is fine again. everyone can open it again. (the new filename). If I make changes to the file and save the changes (with the original file name) the problem persists. It is only when I create a new file name (save as) that the new file is accessible by all. The original file remains inaccessible from macs. I have since noticed that this can happen even while a mac 10.5 machine has the file open, and it can be fixed by that mac machine by "saving as" and calling it a different file name. All of the MAc osx machine are affected, but I can always (so far) open it with my XP machine. All of the times it has happened have been with Adobe InDesign files (InDesign CS... they insist on using the old version). So far it has only been happening on one OSX 10.5 client with one exception. It has happened once on a different OSX 10.5 client. these are not the only two 10.5 clients that we have on the network. It only happens when you save the file. As I say this has happened five times now and although I have been able to fix it every time in a matter of seconds, it is considered a deal breaker by those around me.(I am the sole IT guy in the office). I have scoured the web with absolutely no results and I have searched through these forums and nothing has turned up. This only happens with InDesign and it didn't used to happen when they were using one of the mac 10.5's as a server. I have been trying to see some pattern of find some clue but have drawn a blank. It appears to be completely random. I would have suspected the problem to be with the client machine except that it has happened once with another client, and it never happened when they used the mac a s a server. It has never happened to the same file twice. here is my Samba conf file, it is the default conf file with these changes: Code: security = share and at the end: Code: [JAJA] comment = Ubuntu File Server Share path = /mnt/JAJA browsable = yes guest ok = yes read only = no create mask = 0755 the next step was to do this: Code: chown nobody.nogroup /mnt/share any help on this or even any form of clue would be greatly appreciated. Thanx in advance Edit: It happens almost on a daily basis now. Edit again: 25/03/2009 The problem has new symptoms: When any of the 10.5 machines moves a .indd file from one folder to another, most of the image links are broken and instead point to the folder location of the new folder that the file has been moved to. The images then need to be re-linked to their respective images. Like I said though, this doesnt happen to all of the images, and doesnt happen to every file.
Hi almeister9, I've exactly the same problem. Unfortunately I have no solution yet, but perhaps a roadmap for a solution. It must have something to do with the xattr (extended attributes) implementation of Leopard. You will probably able to copy your sticky alias file to a local disk of your Mac and it will behave identically as it is stored on your samba share. Open the Terminal.app Code: cd /Volumes/[I]my_mounted_samba_share[/I] ls -l@ I bet all of the sticky alias files have an xattr called 'com.apple.FinderInfo'. Confusing enough, not all of the files with extended attributes are sticky and not even all of the Indesign files. Code: xattr -d com.apple.FinderInfo [I]my_sticky_file[/I].indd will remove the attribute from the file and the Finder will display and handle it as a regular one. So far for the moment. As I said, only a roadmap... Holger
So I am not going insane after all. Thank you deeply for your reply. I am not at work at the moment but I will definitely try this out on Monday. The only clue I had to this problem was that it only happened when the file had been opened on a Leopard machine, but it would affect the way Tiger machines could handle it as well. The problem never showed up after being opened by a Tiger machine. Also the Windows machine was never affected and could always open the file. Now I have something to go on. Thank you so much for your reply. I will continue my investigations and If I find anything more I will definatley let you know. Cheers Al
... but once a Leopard machine did corrupt a file, in my case Tiger machines are affected as well. Maybe a bug in Leopard. I've no idea how MacOS stores the informations for extended attributes on a samba share. The implementation of xattr is completely different from linux. Try to do on your Linux box: Code: getfattr -d [I]my_sticky_file[/I].indd and you will see, Linux doesn't know anything about the extended attributes Leopard or Tiger has created. The big question is, where does MacOS stores the information about extended attributes in general and in special on a samba share? Is it a kind of metadata section in the file, is it the suspicious .DS_Store? After removing .DS_Store in all directories, I disabled the creation of it temporarily (http://www.greci.cc/?p=10). I have no negative feedback about it, but it's too early to say the problem is solved. Holger
No Joy with testing If I try as you mentioned ls -l@ I get this Code: /mnt/JAJA/JAJA_DATA/Trade/SPwip/sp140wip/content$ ls -l@ ls: invalid option -- '@' Try `ls --help' for more information. same if I try sudo If I try xattr -d com.apple.FinderInfo my_sticky_file.indd I get this Code: /mnt/JAJA/JAJA_DATA/Trade/SPwip/sp140wip/content$ xattr -d com.apple.FinderInfo sp140_16-17(RoadshowFeature).indd -bash: syntax error near unexpected token `(' If I try getfattr -d my_sticky_file.indd I get this Code: /mnt/JAJA/JAJA_DATA/Trade/SPwip/sp140wip/content$ getfattr -d sp140_16-17(RoadshowFeature).indd -bash: syntax error near unexpected token `(' I am unable to cd to the folder using Teminal on Mac. I can cd /Volumes but not cd /ShareName. If I ls I can see WORKGROUP;UBUNTU but cannot cd to any combination of cd /WORKGROUP , cd /WORKGROUP; , cd /WORKGROUP;UBUNTU , cd /UBUNTU , cd /;UBUNTU , cd /JAJA (sharename). If I delete the .DS_Store file (by browsing to the folder with XP) it doesnt fix the problem, but if I delete the file ._sp140_16-17(RoadshowFeatue).indd for the affected file sp140_16-17(RoadshowFeature).indd then the problem IS fixed. I am now more confused than ever. I am attempting this from my xp machine via ssh into the Ubuntu box. Full re-install last week so Ubuntu 8.10 Server and latest Samba.
Keep cool Hi Al, first of all: Don't panic! Sorry for my poor English that is probably the reason for confusion. Yes. That's right. The bash compiled for Linux doesn't know the '@' flag. The bash compiled for Darwin/MacOS knows it very well. You should do the command on a Leopard machine with the application 'Terminal.app' that resides in the utilities folder. The problem has nothing to do with your Linux box. Nearly the same here. But the filename is the first problem, so the bash ist unable to figure out the second problem that the command is not found. '(' and ')' are special chars in every shell. You have to mask them Code: hlx@ic2q-2400 ~ $ [I]some_command[/I] sp140_16-17\(RoadshowFeature\).indd or wrap single quotes around Code: hlx@ic2q-2400 ~ $ [I]some_command[/I] 'sp140_16-17(RoadshowFeature).indd' Anyway, xattr is a Darwin only command! O.K. Nearly done. The command is correct for the platform. Do Code: getfattr -d sp140_16-17\(RoadshowFeature\).indd And you will see nothing as a blank line. That's good in unix like universes. The command is executed successfully, but there is no extended attribute. Another tip: Make intensively use of the autocomplete feature of any shell (irrespective of MacOS or Linux). The tab key is your friend! http://ubuntu.wordpress.com/2006/01/28/turn-on-bash-smart-completion/ You have definitely to figure out the mount path of your samba share on your MacOS machine. In your case it should be '/Volumes/JAJA'. Otherwise we can not proceed. Unfortunately a useless procedure. Once you have executed my suggestions successfully, I will tell you why. The proverb "For minor problems, reboot. For major problems, reinstall" is not valid for open source. Don't even think about it! Holger
Getting there Thank you greatly for you patience and perserverance with this. I have been able to browse to the folder on the Samba Share, using the Terminal on a 10.5 machine. I can now run the ls -l@ command and I see the attributes which results in Code: jas-imac:content ja$ ls -l@ total 34376 -rwxrw-rw- 1 ja staff 4751360 2 Mar 12:32 sp140_01.indd -rwxrw-rw-@ 1 ja staff 2297856 22 Mar 16:06 sp140_06-07(News).indd com.apple.FinderInfo 32 com.apple.ResourceFork 22802 -rwxrw-rw-@ 1 ja staff 4087808 23 Mar 10:40 sp140_11(News).indd com.apple.FinderInfo 32 -rwxrw-rw-@ 1 ja staff 3223552 20 Mar 18:29 sp140_16-17(RoadshowFeature).indd com.apple.FinderInfo 32 com.apple.ResourceFork 6064 -rwxrw-rw- 1 ja staff 1118208 23 Mar 10:30 sp140_16-17(RoadshowFeature)copy.indd -rwxrw-rw- 1 ja staff 856064 20 Feb 15:22 sp140_24(BuyersGuide-April).indd -rwxrw-rw- 1 ja staff 1265664 2 Mar 12:48 sp140_24-25(BuyersGuide).indd Interesting how there are two files with the attributes but only one is affected. (sp140_16-17) I then can go back to My Linux box and tried to run the command getfattr - d but was told that attr wasnt installed. so Code: apt-get install attr then Code: getfattr -d sp140_16-17'(RoadshowFeature)'.indd which seemed to go OK. The effect it had though was when I looked in the folder using finder on 10.4 it sees all the files that didnt have any attributes now having no icon, but it can open them. Using Finder in 10.5 it sees them all as having their icons, but the file in question is still seen as an alias i9n both 10.4 and 10.5 and cannot be opened, and if I use the terminal to ls -l@ it still shows the same attributes. Were definitely getting somewhere here though and I really do appreciate your patience and efforts with me on this.
Adding more info We have now discovered that when InDesign files are moved from one folder to another (regardless of whether they have had there "._" files deleted or not), alot of the images in the InDesign files lose there linking information and need to be re-linked. It seems as if when these InDesign Files are stored on the Samba Share, the important data contained within it is being damaged somehow. At this stage I would like to add that I have mounted the DATA HDD by having this entry in /etc/fstab Code: /dev/sdb1 /mnt/linuxstore ext3 defaults 0 0 I add this becasue it is almost as if the Samba and its HDD cannot understand the files living on it properly
step by step And now get rid of the extended attribute in the way I mentioned in my first comment. Use Terminal.app on your MacOS box (Tiger or Leopard does not matter): Code: xattr -d com.apple.FinderInfo [I]my_sticky_file[/I].indd Unlike the getattr command on Linux the flag '-d' of xattr means not dump but delete. That's the key to "repair" a corrupted InDesign file at least in my case. The only things you will loose are the funny color labels, Spotlight comments and other useless Finder Info related stuff. As opposed to your case, I never saw the attribute 'com.apple.ResourceFork'. Did the file was stored on an Apple File Server Volume before? Anyway get rid of it too: Code: xattr -d com.apple.ResourceFork [I]my_sticky_file[/I].indd Now that your affected file the Finder should display as a regular one, you'll have to open it maybe with the "Open with..." dialogue. As you told me, you removed the correspondent '._*' file. Any MacOS client will rebuild the file every time it is accessed. Don't even try to append the line: Code: veto files = /._*/ in your central smb.conf of your Linux box. MacOS is not able to access a share if it can't write a dot underscore file. http://support.apple.com/kb/TA20578 At last execute my suggestion from my second comment. Get permanently rid of the .DS_Store file. Read here for background information and follow the instructions from here. And finally forget your fstab. Your problem has nothing to do with the underlying file system, cause in my case it is ReiserFS. Good luck Holger
Now we are getting somewhere Hi Holger, I have done as you suggested. Code: xattr -d com.apple.FinderInfo sp140_16-17'(RoadshowFeature)'.indd and xattr -d com.apple.ResourceFork sp140_16-17'(RoadshowFeature)'.indd and you were correct. Using Finder I can double click the file and it now opens. This is one step closer as now the problem can be solved by a mac without the use of WinXP. I have also started preventing the machines from writing the .DSStore files to the Network using your suggestion Code: defaults write com.apple.desktopservices DSDontWriteNetworkStores true So... We now know what is happening, and how to fix it when it does happen. Now we need to work out how to stop it from happening. Would I be correct in assuming that what we are trying to achieve here is to prevent the creation of the extended attributes? And secondly, are these extended attributes only created by 10.5 or does 10.4 create them as well?
Leopard is the Culprit. After a little more investigating I have come to a number of conclusions. My investigations have uncovered two more symptoms: 1. Randomly, but quite frequently, when a Leopard machine moves a .indd file from one folder to another, the image links are broken on MOST of the the images (but not all) and now point to the location of the new folder that the file has been moved to.These have to then be re-linked to their images involving a painstaking "search" for the image files then using the "browse function of the re-link manager to relink them. Again Leopard only. 2. Randomly, when a Leopard machine double clicks on a .indd file in Finder, or uses File - Open from within InDesign, to open a .indd file, it copies itself and opens the copy instead. As with the first and second problem, once it happens it affects the 10.4 Tiger machines as well and the only way to rectify the situation is to use the InDesign - File - Open command and click the bullet "Open Original". My Conclusions are as follows: 1. Although the removing of the extended attribute com.apple.FinderInfo will fix the alias problem, the actual existence of the attribute does not cause the problem. I have noticed that many files have this attribute but do not get the alias problem. 3. There also seems to be no way of preventing the creation of these extended attributes anyway. 2. removing the attribute com.apple.FinderInfo does not fix the broken links problem. 4. If only Tiger 10.4 machines are used, there are absolutely no problems, same with WinXP 5. Edit: statement removed because I was just whingeing 6. Edit: statement said I was thinking of going back to using one of the Leopard machines as a server but again I was just whingeing. Once again I would like to thank all for your help and if any body can shed any light on this what so ever, either now or in the future, I would greatly appreciate hearing from you. Cheers Al.
Hi Al, sorry for my late answer. My problem is that I have only randomly access to a MacOS machine specially a Leopard one. So not all of my following considerations are tested actually. I agree most of your conclusions, but some not. Maybe not the fault of Leopard. What's the version of your InDesignCS application? Mine ist CS1. And I detected the problem long before Leopard was established in my environment. I think it has to do with the directory separator. Historically MacOS is using a colon (':') and mostly all other plattforms use a slash ('/'). A short google request for indesign colon slash link is a good starting point to waste the rest of your life Are you absolutely sure that you run the command Code: defaults write com.apple.desktopservices DSDontWriteNetworkStores true for every user who has access to your samba share irrespective of he is using Tiger or Leopard? And did you really get rid of the .DS_Store file in each directory of the samba share? Otherwise do on your Linux box Code: cd /mnt/JAJA find . -name .DS_Store -exec rm -rf {} \; That's what I told you and I found no explanation for it. Wrong. Take care that no client writes a .DS_Store file to the share. See above. Yes. As discussed already. Except the link problem of InDesign. There must have been another change in your environment. Apple's support for foreign platforms is a nightmare in general. Specially the support for cifs is ambigous. But do yourselve a favour and think about twice if LeopardServer is a real solution for you. Specially the Samba sources of Darwin are very close to the original and it wouldn't surprise my if you run in the same problems you actually have. The discussion was a bit self-referential. Feel free to copy hole thread to a more ambitious platform/list/forum/group. Good luck Holger
More Info to hand Hi Holger, Thanks for your persistence with this. I must apologise for the tone of my last post. The frustration was getting the better of me. After feeling I was getting nowhere, I decided to turn my investigations to InDesign itself. I went to the Adobe support knowledge base and very quickly found the following: 1. http://kb.adobe.com/selfservice/viewContent.do?externalId=330232 I found that doing it through Help > Updates didnt work and I downloaded the actual update and distributed it to the machines. The April 2005 Update is to allow InDesign CS to open .idx documents created in CS2, however if Adobe says it will fix my problem, then I am willing to give it a try. I have installed the update on all machines. I have also let everyone know that if the updates work, it will not fix the existing problem, only prevent it from happening in the future and any existing files with broken links will need to be re-linked, but should be fine from then on. (If Adobe are correct) 2. I found this pdf about Leopard support of Adobe products http://www.adobe.com/support/products/pdfs/leopardsupport.pdf?promoid=DJHBQ chart on page 2 InDesign CS2 and earlier is listed under "NOT DESIGNED For Mac OS X Leopard" and under the column "NOTES ABOUT Compatibility" it says "Likely to encounter issues for which there is no resolution." Enamourmed with this information, I put forward a proposal to the company directors stating that (apart from the links issue) I believed that the problem was being caused by the incompatibility of CS with Leopard. We have now purchased a copy of InDesign CS4 as well as Photoshop CS4. I have installed it on one of the Leopard machines and we will be testing it vigorously. If the problem doesn't appear in the CS4 test environment then we will be buying CS4 for the rest of the machines. I sincerely hope that this will sort this problem out once and for all, as the staff are very keen to be using the latest software and quite excited about CS4. Also, you are correct in assuming that I haven't done the .DSStore suggestion to all machines as yet. I will be doing this to the remaining machines Monday morning before everyone gets in and also your suggestion for the Linux box. I understand that this may make it difficult to determine which solution actually solved the problem, yours or Adobes but my time has run out and I need this resolved. Once again I must thank you sincerely for your help with this matter and if any more information comes to light I will definitely post it here. Cheers Al
