Strange problem when copying files to NAS

At least apple should propose a NAS of their own, instead of making problems with all the other NAS....

I wonder to watch Tim Cook, one day, showing a slide at Apple event, "Now, with "Mountain Yosemiti" you can easily copy file through NASs device without getting any windows-like errors"....

Hi

Nice suggestion (I wanted to turn off . files for shares anyway), sadly none of the suggestions in this thread actually solved my problem when copying from one SMB share to another.

Turning off icon previews and not clicking on a file before copying allowed some files through occasionally, and turning off the default for writing hidden files on shares helped too, but I was still left with a failure rate of about 50% when copying multiple large files.

Seems to me like some sort of race condition which results in the file being busy at the point where writing the file finishes (it's always at the end and never in the beginning or middle).

I would be tempted to say that SMB on the Mac is broken (I'm using Yosemite by the way), but actually I think it is the finder and not SMB as when I use PathFinder to copy the same files it works like a dream every time, and that is probably using excatly the same low level libraries to access the filesystem.

So right now I don't have a solution other that to say that with PathFinder works perfectly, so if you are happy to try a different finder you should give it a try and see if it works for you (I am not in any way affiliated, just a fan of it).

I have been unable to drag and drop large files, even onto the Desktop, let alone onto my NAS - I get the dragged files freezing in the middle of the screen or I get the 'unable to copy / file in use error'.

Talking to Apple Support, they had me set up a new User, and then within that new account, the trouble went away. This pointed to the StartUp items being run in the original troublesome account,

I have deleted all of my 3rd Party programs and then installed them one by one until the problem came back, and in my case (Macbook Air 5,2 running 10.10.3 Yosemite) I found it was DropBox causing the conflict. I have DropBox running in the Menu Bar (top of screen) and disabling sync (bottom left corner) stopped the file copy problem.

Same problem here. I've been using a windows server with my macpro for years, upgraded to Yosemite and now I can't move large files to my media shares. Error "The item “xyz” can’t be copied because it is too large for the volume's format."

Tried a bunch of workarounds and sadly the only thing that worked for me is the third party app Pathfinder. If I boot into my old Mavericks partition all works fine... 😟

Similar problem coping via smb using Yosemite and the problem does seem to be smb protocol related. Tried all the other forum suggestions but I think I have resolved it because there is a neat piece of software on MacUpDate called SMBconf which lets you switch between SMB1 or SMB2/3. Fingers crossed but so far large movie files copying across to the WDLiveTV without 'that fives seconds to go... file in use' issue.

Hope it helps you too...

http://www.macupdate.com/app/mac/50723/smbconf

I've also had weird issues between my Macs and my QNAP NAS. I THINK I may have finally closed in on a solution. I wish I had stumbled on this thread before now; I've been thinking I'm the only one with issues.

Anyway, for what it's worth, here are some conclusions I've reached (for now) in no particular order:

1. Do NOT use more than one protocol unless you need to and you take great care. OS X considers a share via SMB to be different than a share via AFP. (This doesn't appear to be true between two Macs, just between a Mac and another type of machine). You can prove this by creating a Photos or iTunes library on your NAS with AFP, then switch to SMB and try to start Photos or iTunes. It will complain that the library is missing and you'll have to point to it manually before you can use it. I found this out the hard way when an iTunes library got completely hosed. Several songs/movies/podcasts would be recreated with a version number (file, file 1, file 2, etc.) because of this. I could clearly see what was going on by looking at "iTunes Library.xml". What a mess!! Good thing I still had my original library.

2. AFP works much better than SMB ... until it doesn't. QNAP's AFP implementation is apparently some third party or open-source non-Apple solution that works pretty well, but not 100% reliably. Since Apple is deprecating AFP, you could say that it's as good as it's going to get, so maybe you should stay with it. I did for a while but got tired of issues continuing to crop up, so I figured I'd go with SMB. Besides, SMB is the future for both Windows and OS X.

3. SMB is a work in progress. Apple is dumping GPL-licensed SAMBA and rolling their own solution. It has been improving and I'm sure it will continue to do so. That said, there are some issues and a major one appears to be NTLM authentication. Starting with Yosemite (apparently), Apple uses only NTLMv2 to authenticate SMB connections. The default on ALL Windows installations prior to Windows 8 is to use NTLMv1 but allow negotiating to v2. What's weird is that Microsoft has tech notes out starting in the 90's!! talking about how insecure v1 is and you should use v2; why is that not the default? So I don't really blame Apple for this one. Anyway, long story short, I checked the box on my NAS that said "Allow only NTLMv2 authentication" and voìla, my SMB issues went away ( ... almost, see below). I had erroneously assumed that meant forcing the use of an older method as opposed to say "NTLMv3" (which doesn't exist as far as I know). Anyway, for those whose troubles started with Yosemite, this might be the problem. Regardless, knowing what I know now, I would avoid NTLMv1 whenever possible.

[As an aside, it's really easy to reconfigure Windows NT - Windows 7 to only use NTLMv2. It's just a registry entry that can be controlled by the "local security policy" control panel. Just Google it, it's easy to find. Windows 95, 98, and ME can be configured that way also but you've got to install the Active Directory Client Extension. I've done this for Windows 98 that I run in Virtual PC under XP, Win 8, and Win 2000 under Parallels desktop. It just works awesomely. Windows 8 seems to work just fine out of the box and that registry entry doesn't exist.]

4. After a few blissful days of absolutely no SMB issues, I had Finder lock up and extreme weirdness when trying to back up some large files to my NAS, some of which happened to be packages (mostly Parallels virtual machines). Things were really hosed and re-launching Finder just made everything hang. What fixed that and left me where I am now was UN-checking QNAP's SMB setting: "Enable asynchronous I/O". This had been un-checked by default, but I had enabled it at some point. Interestingly, in testing this, every file so far copies much faster with this unchecked. I believe the expected behavior is for async to be somewhat faster on average. Possibly with a bunch of very small files, that may be true - I just haven't tried.

So here I am and everything appears to be working well so far. I hope this helps others.

Hmm, apparently no way to edit a post. Anyway, reading through this thread got me to wondering. Some said that putting files into a folder, then copying the folder to their NAS worked just fine. I wonder if NTLM authorization gets negotiated for "my folder full of files" and both sides understand that, so everything works.

With a package, which is really just a folder, perhaps Finder is negotiating for a single file, then sending what looks to the NAS like a bunch of files. I suppose I could read up on it, but it does seem like most of my SMB problems have been with packages.

I encounter this problem copying multiple files (usually images) from my Macbook Pro runing Yosemite 10.10.2 attempting to copy to an older Seagate NAS GoFlex Home. The copy operation would fail after copying the first file telling me the 2nd one was in use. I would then pick the 2nd file and be able to copy it, making the process cumbersome. Using SilverSkyRat's process above (deselecting the files or folders first) I was able to select-without-preview an entire folder, and copy all of the files successfully. I suspect that there's a communication or compatibility fault between the old NAS and OSX's preview feature, since I don't have this issue with my Ubuntu machine working off the same NAS. Thank you to everyone that contributed to this thread, especially Linc Davis and SilverSkyRat.

I found an app that copies consistently. Forklift does just fine. I've been able to copy in folders in finder but not individual files if they're listed in finder. However, I set Forklift to connect to my router's NAS and dragged all the files in the folder I wanted to copy over and they are copying without issue as I type this. So I'm guessing this is a Finder issue specifically.

Hi Dan,

Tried putting a movie file into a folder and copied to my WDLiveTV over home network and it worked! Tried several more and no errors re 'File is in Use'.

I had reported the bug to Apple and sent them lots of system logs as they requested but going to add this very simple pointer to the problem!

iMac Yosemite 10.10.3

Hi Basil,

I can't take credit for the folder fix; I was just repeating something someone else on the thread had come up with. But I'm glad it's working for you, of course.

All I've really come up with on my own is (1.) forcing NTLMv2-only authentication, (2.) disabling asynchronous I/O, and (3.) using ONLY SMB, meaning AFP is disabled. I'm also using SMB 3 for what it's worth. I've had no issues since doing this (fingers crossed). Everything just works the way I would expect, including Finder preview icons.

What I WAS wondering, without spelling it out very well, was whether Finder was not properly specifying that it was copying a folder when copying a "package". (Not knowing how SMB works, this is just really a shot in the dark.) OS X has several "file types" which are really just a folder. Applications are like this: if you right click on "iMovie.app", you can click on "show package contents" to see what is inside the folder called "iMovie.app". Finder presents this as just a single file, but the underlying OS properly sees the folder hierarchy, which may be why copying a "package" from the terminal works when copying with Finder doesn't.

This *appears* to only be a problem when using NTLMv1. After setting things to use NTLMv2 only, I can copy anything either direction and it works great. So far it just appears to be me that is having luck with this approach. In any case, each update from Apple has really increased the reliability and stability of Yosemite so I'm sure it will be fixed fairly soon.

Hi,

I have a very similar problem, potentially the same: "error message saying that the file can't be copied because it is already in use by another application."

The difference is that I try to copy files to a SMB volume which I access over VPN (CISCO AnyConnect, because the admins selected that solution). When I am connected locally to the same SMB volume (in my office), the problem does not show up. I am using 10.10.4.

The hint from SilverSkyRat to use the Terminal and the cp command was helpful (Thanx!!), this allowed to copy files that triggered the error in the Finder. From this I conclude that it must be a Finder bug, because if the Terminal cp command can do the job an intact Finder must be able to do it as well.

In my case, changing the View options (uncheck Show icon preview) had no effect.

However, deleting (a quite long list of) the ._* files on the server and in the target folder (by using the Terminal and "rm ._*") did help.

i'm using a popcornhour, but same concept copying over a network to an smb share.

i did the following on a particularly stubborn file:

turn show icon preview on, then off (it was originally off)

did a get info, locked the file then immediately unlocked it

made a new directory on the popcornhour, moved all of a particular shows files into that, deleted the old folder

- i believe the ph treats permissions differently with regard to folders created using the device's UI versus folders i create from my mac

opened the file, in this case a quicktime file on my mac, then quit out of the application

then it copied.

Needing to get round this same problem I used my windows PC which can see both the Mac and the NAS to copy the 500 files from Mac to NAS. On the Mac it would hang with the "file in use" message every 5 or 10 files so it was getting tiring to copy over in small batches. Using the windows machine to perform the copy worked first time, for all the files in one go, exactly as you'd expect it to. This is obviously not a solution to the problem but hopefully helps some people, but more to the point it surely suggests there is nothing wrong with the NAS and something wrong with the Mac or with Finder.

Long time since I posted on this thread, thought I would share (pardon the pun) my experience since. Everything working fine, it started working properly after both Apple and my QNAP updated my MacBook and my QNAP NAS firmware.

As well as filing a bug report with Apple I also got QNAP tech support in so it was an issue on both sides it would appear.

It got even better when I upgraded my router to a newer one capable of 5GHz Wifi.

🙂

Adrian.