Previous 1 10 11 12 13 14 Next 199 Replies Latest reply: Apr 8, 2010 8:35 PM by Robert Bosch Go to original post
  • fakeollie Level 1 Level 1
    Very strange. Running dot_clean has helped me about half a dozen times, and have not failed yet. We're probably looking at different (albeit similar) issues here.

    I'm sorry the workaround didn't work for you guys.

  • TripleChime Level 1 Level 1
    I must say first off that I haven't read ALL of the pages of this thread, so this may well have been mentioned before, but what works for me and my NAS is to use FTP to transfer files to and from the NAS.

    The NAS is a Macally which appears to use some form of Linux or freeBSD for the OS, but if I try to transfer files directly using 10.6.2 I do get the -36 code.

    FTP is working OK. I have tried Cyberduck, YummyFTP, and FileZilla. The only issue I have seen so far with this FTP method is that somehow a few of my files have gotten a slash into the filename itself which the Mac OS seems to access on local disks OK (not sure how), but these files cannot be copied to the NAS without deleting the slashes which the NAS' OS can't handle since these filenames are actually invalid.

    From what I understand the NAS is probably not saving the metadata (haven't copied any files to which the metadata is critical), but this would be true via Finder SMB access as well.
  • CarCode Level 1 Level 1
    Correct, it seems there are different reasons for error code -36. Some people can't even copy, other like me can't launch a file which has worked before.
    It might be possible the password settings for smb clients are the reason for copy failures.

    So copying works here back and forth with windows computers, linux computers and a NAS via smb with no problems.

    However launching a file with Finder from smb clients (e.g. open a picture in Preview) works with the smb computers but not when the file sits on the NAS. The thumbnail is shown in Finder but Preview fires up an error message: Preview could not be started, error -36.

    Before the update to Snow-Leopard it has worked however.

    Because anything works fine with the other clients but not with the NAS, I guess there is some trouble of different Samba versions between Snow-Leopard and the Samba version running on the NAS. Samba version has changed with Snow-Leopard, but I can't change the Samba version of the NAS to make things running as before.
  • William Kucharski Level 6 Level 6
    Mac OS X
    CarCode wrote:
    Correct, it seems there are different reasons for error code -36. Some people can't even copy, other like me can't launch a file which has worked before.

    That's it exactly.

    A -36 error means the Finder encountered an I/O error attempting to perform an operation (technically it's a Mac OS X ioErr.)

    There are a multitude of things that could cause it from network difficulties to a bad hard drive, so the workarounds given here will not eliminate every cause of the error.

    Unfortunately one common cause seems to be using a newer version of Samba (like that included with SL) to communicate with an older version (as implemented on many NAS devices.)
  • CarCode Level 1 Level 1
    <edited by host>

    In most cases it is impossible to update a Samba version running on a NAS. It might however possible to lower the restrictions in a given Samba version to be friendly to different Samba versions running in a network by using the commands in the smb.conf config file settings.

    Any Samba specialist is asked here for suggestions.
  • brian-c Level 1 Level 1
    I isolated the problem some. It occurs when you try to copy a resource file in the format "._<whatever>" from a HFS volume to a CIFS share from within the Finder. To demonstrate:

    1) Enable viewing of invisible files (via program MainMenu, or via "defaults write AppleShowALlFiles TRUE;killall Finder" in a terminal)
    2) Open a the directory that will not copy to the CIFS share, you will find at least one file prefixed with "._", it is a resource fork file.
    3) Try to drag just that resource fork file over to the CIFS share, it will produce the infamous "......can't be read or written. (Error code -36)" error.
    4) Close the error and try to copy the file again, you will now receive a different error, "The item ..... can't be replaced because it's invisible" !!!

    I think that the Finder has a feature where it hides resource fork files on CIFS shares from itself, and probably other non-HFS volumes. When copying such files over to a CIFS share though, it will freak out and produce the -36 error when they suddenly "disappear" after being created.

    I spent hours trying various options to work around this issue on the server side Samba 3.0.X and 3.3.X and failed miserably. I think Apple is just going to have to patch the bug.

    As an (annoying) work around, I found that you can delete all resource fork files from the directory you are trying to copy. That worked around the problem %100 of the time for me. For example, if the directory "Financial Data" on your desktop won't copy over to a CIFS share, you can do the following:

    1) Open a terminal, run: find "Desktop/Financial Data" -name '._*' -delete
    2) Close the terminal, copy "Financial Data" over to the CIFS share
  • Carey Jung Level 1 Level 1
    I've submitted bug report 7570870 on this, for what it's worth. The only workaround I have is to compress the folder, move the resulting zip file to the new location and then unzip it.

    22-Jan-2010 03:44 PM Carey Jung:
    Summary: Copying folders on Snow Leopard from a CIFS share to another location on the CIFS share or another CIFS share fails if the folder contains hidden resource fork files ("._*"). The copy operation fails with the following error:

    "The Finder can’t complete the operation because some data in “XXXX” can’t be read or written. (Error code -36)"

    Steps to Reproduce:

    - connect to Samba share (any recent version. we've confimed on Samba 3.0.x and 3.3.x)
    - create a folder on a CIFS share, e.g., on a Samba share
    - copy or create a file, like an Excel file (.xlsx) in the folder and confirm ("ls -a") that a corresponding resource file (._*.xlsx) exists in the folder.
    - now copy and paste the folder into a different location on the share.

    Expected Results: The folder gets copied to the new location on the server.

    Actual Results: You get the error above.


    Notes: This is a new problem introduced with Snow Leopard. With the new NTFS streams default in Snow Leopard, it appears that the Finder is hiding the Apple Double files from itself in CIFS shares. It copies the ._ file over, but then apparently can't stat it, so gets the -36 error. We've found numerous reports on line of users experiencing the same problem with Samba shares, NAS devices, etc. The only workaround we've found is to compress the folder, move the resulting zip file to the new location, and unzip it.

    22-Jan-2010 03:45 PM Carey Jung:
    'Screen shot 2010-01-22 at 3.41.55 PM.png' was successfully uploaded
  • Oliver Kess Level 1 Level 1
    It seems as if 10.6x has a problem with the NTFS ownership.
    Reassign the owner to "network service", this is a local user of the NAS (in our case a netapp bound to AD)
    until Apple fixes this mess, this is the way to read / write files from a SMB share.


    credits for this hint goes to Chris Eads:
  • XenData Level 1 Level 1
    I noticed that there are a couple different discussions on this topic. Also, as mentioned earlier, error code -36 is a generic error code and can have many causes. That being said I have found the solution to my issue. The problem was introduced in 10.6 and has to do with writing with NTFS Streams instead of resource forks. The solution is to create a /etc/nsmb.conf file, if it doesn't already exist, and put in the following:


    You will need to use sudu to create the file.
  • chad von nau Level 1 Level 1
    I have found 2 workarounds for the Error -36 problem at my office.

    We had Snow Leopard 10.6.2 Macs joined to our Active Directory domain, but we were logging into the computers w/ local accounts. We connected via samba to our linux servers, logging in w/ AD accounts. Some servers would let us copy files to the server normally w/ Finder; other servers gave us Error -36 and would create a 0 byte file. We were able to delete and move files in the Finder on all the servers, even the ones that gave Error -36 on copy. Copying files from the Terminal also worked on all servers. We tried putting "unix extensions = no" in our smb.conf files, and it did not help.

    We found 2 workarounds:

    1. Unjoin your mac from the domain & restart your computer. With the machine not on the domain, we didn't get any more Error -36's when copying.

    2. Leave the computer on the domain, but only log into it w/ a domain account. This also let us copy to the problem servers.

    Hope that helps someone.
  • Oliver Kess Level 1 Level 1
    chad, you should not have to unjoin your domain.
    Follow the hint from Chris Eads:
    This fixed it for me while I remain bound to my AD domain and can do a single login to my account and my shares.
    I also want to make clear that no editing of /etc/nsmb.conf was necessary as well.

  • chad von nau Level 1 Level 1
    Thanks Oliver, but the problem on the page you linked to is slightly different from the one we were having. There are tons of SAMBA bugs in Snow Leopard.
  • herveyw Level 1 Level 1
    This from Apple:

    My NAS, a Synology Diskstation exhibited the -36 problem a while back but was fixed by a firmware update from Synology and I no longer have problems copying folders, files or bundles.
  • vinodh98 Level 1 Level 1
    I have a similar setup here with SAMBA Version 3.4.2- running on top of OpenSUSE 11.2. Had the same issues, while troubleshooting i noticed that in my smb.conf file had the "veto files = /.*/" directive set. Once i removed that, was able to copy files/folders through finder without any issues.
  • gswd Level 1 Level 1

    Thank you so much for posting that link to the apple article. I took the steps listed for disabling the stream, and now I have the functionality of my NAS back without having to ftp files to and from my local drive.

    BTW, for those that might be wondering, I have a NexStar LX NAS box and this worked.