Currently Being ModeratedSep 12, 2012 2:15 PM (in response to bonfire)
Did you manage to find a solution? Because I have a similar problem, and it is frustrating.
I have a Drobo FS NAS, connected to my 2008 imac with ethernet 1gbit, and I have a similar, erratic behaviour.
Currently Being ModeratedSep 12, 2012 2:29 PM (in response to akouris)
Nope. The only thing that works consistently for me is to completely avoid using Finder when dealing with my NAS... Can you mount & copy fine from the command line too?
FYI - I updated OS/X to 10.8.1 the other day - that didn't help either. At least it didn't screw up the ability for it to work from the command line.
Currently Being ModeratedSep 13, 2012 12:06 AM (in response to bonfire)
I have also updated, but with no improvement.
I get consistent speeds with other copy methods, command line, or the muCommander which has internally a similar approach http://www.mucommander.com
Whenever Finder performs a task, everything will slow down.
I am thinking of temporarily setting up a windows server, share the NAS volume through that, and see if I have a more consistent connection that way.
Currently Being ModeratedSep 13, 2012 2:18 PM (in response to akouris)
I just tried mucommander as well and yes, indeed it seems to work fine! I guess I can use that to help family members access the NAS. Thanks for the tip. Certainly not optimal, but....
However, seeing your post motivated me to make another attempt to figure out what the heck is going on. I think I figured it out.
Did you by chance back up your home directory to your NAS, then restore your home directory from the NAS backup? I have done that several times, and I had noticed that it had dropped the access control list bit from the permissions. For example, when I checked permissions on my home directory, I got this:
> ls -led /Users/rob
drwxr-xr-x 67 rob staff 2278 13 Sep 13:41 /Users/rob
But when I checked a newly created user named "testing", I got this:
> ls -led /Users/testing
drwxr-xr-x+ 11 testing staff 374 13 Sep 12:52 /Users/testing
0: group:everyone deny delete
Note that the "e" prints the ACL table for the specified file/directory, and that there is a + at the end of the permissions indicating there are ACL rules for this directory. I don't know much about ACL... but I just recreated an ACL entry on my home directory to match the one on the new "testing" account I created. So I did this command:
> chmod +a "group:everyone deny delete" /Users/rob
I also did the same on my desktop directory like this:
> chmod +a "group:everyone deny delete" /Users/rob/Desktop
After that, Finder actually seemed to work fine. I've only played with it a few minutes now, but it seems to work fine after a dozen file and folder copies back and forth.
I suspected that I also had some other ACL issues with other files/folders, so I also discovered that you could repair permissions and ACL on Apple based files & directories using disk utility. So you can try this:
Open Applications -> Utilities -> Disk Utility
Then select the hard drive that OSX is on (in the left pane)
Then click "Repair Disk Permission" (in the right pane)
Mine made several changes in the Library directory, both to perms and ACL. After running that, my Finder still works fine with my NAS. In fact I fired up my second NAS and both seemed to work fine, even when copying directly from one NAS to other other or to any other disk.
So.... My lesson here is that after restoring an account from a backup that was stored on the NAS, that there are probably some permission and acl issues to fix first!
I hope this works for you!
Currently Being ModeratedSep 14, 2012 4:31 AM (in response to bonfire)
I don't use the NAS for time machine or home directory backups - I use it as a storage medium for my projects.
Regardless, I often use Disk Utility to repair permissions - usually once a week, so locally my permissions are correct.
You are right - permission rights can create a lot of problems, and as I understand permission issues are even greater with Mountain Lion, because in many occassions Mountain Lion "sandboxing" will not allow apps to use network storage to store critical data.
Setting permissions on a shared/NAS resource is another issue.
Whenever I've tried to do that I've been unable, although I do not believe that the incosistent Finder behaviour on my NAS is related to that.
Currently Being ModeratedSep 14, 2012 8:53 AM (in response to akouris)
Bummer, too bad your problem wasn't as simple as mine....
I had never used the disk utility to repair permissions before, so that new knowledge will undoubtedly save me some future headaches.
Maybe check your system logs (/var/log) and look for system messages that get logged while connecting to your NAS or transferring files? thats where I found the clues to indicate this was a permissions problem for me...
Best of luck!
Currently Being ModeratedSep 22, 2012 1:54 PM (in response to bonfire)
arghhh.... its not working again... OS X updated to 10.8.2... thats the only thing I can think that changed. As per before, copying files from command line works, using Finder chokes the drive completely again. Can't even eject the drive, have to force close Finder (restart it) to be able to eject/unmount the NAS drive via Finder. I tried the same tweak to permissions/ACL as before, but this time that did not help... Is apple reading my thread purposely pushing an OS X update to !@#$!$ me up again?
Currently Being ModeratedSep 22, 2012 11:40 PM (in response to bonfire)
Something really strange is going on.
There is severe incosistency in the way OSX communicates with the NAS.
I do not know whether this is OSX's or the NAS's fault.
The biggest problem that I experience is "browsing" through the NAS folders: I might get instant response for the directory listing, or I might wait for 90 seconds for the list of files to appear.
On file transfers, I might be able to read something at 60MB/sec, and that might drop to 8-9MB and then return to 55MB. On write I might write at 25MB, fall to 12MB, then go back to 20MB.
I tried something else, and I had some interesting results: try accessing the NAS from a virtual windows machine on your OSX. I did that with a Windows XP installation. The results where very revealling. Browsing through the NAS is extremely fast - I get directory listings as if the disc is local. I also get image thumbnails etc. instantly - the NAS does have a consistent response. Transferring files is slower than the peaks the OSX demonstrates (up to 50% less on copy from NAS, 20% less on write to NAS), however the virtual windows machine has consistency - the speed remains always the same.
Since I see speed/response incosistency to the way NAS and OSX connect, even though I have tried both AFP and SMB, someking of other incompatibility exists between the NAS and the OSX.
I am thinking of a way to re-share a mapped NAS drive from a windows virtual or physical machine, access it through the OSX and see whether a consistency in access exists.
Message was edited by: akouris
Currently Being ModeratedMay 2, 2013 3:27 PM (in response to rg_dude)
Thanks dude, that seems to have mostly fixed things for me. I can now eject, or at least force-eject the volume which was imposibble before without restarting the Finder. Also, I notice it has killed constant network access (about 1Mb/sec reading) to Volume_2 when mounted.
Non-raided DNS 323 with default mounts (Volume_1, Volume_2) on OS X 10.7.5.
More Like This
- Retrieving data ...
- This solved my question - 10 points
- This helped me - 5 points