AFP and SMB are really slow from a OSX


arkan

Recommended Posts

Hello,

 

Mounting and working with AFP and SMB shares has been incredibly slow and painful to use.

 

The index listing (when I open a folder with a LOT of files) takes up to 30 seconds.

 

I can hear the hard drives doing A LOT of read operations.

 

I tried with an iOS client to access SMB shares and it was nearly instant.

 

OSX is doing something weird. It's like it was fetching A LOT of information.

 

Do you have also experienced this?

 

 

Link to comment

I use an iMac every day, I have three unRaid servers, one running 6.18, another running 6.19 and a third running b6.2rc3. I access shares on all three of them using SMB. Recently I upgraded my b6.2 server to rc5 and encountered very slow file copying from that server to any destination on my network, rolling back to rc3 resolved that issue. Otherwise, I have no issues accessing shares on any of my unRAID servers from my iMAC over SMB.

Link to comment
  • 2 months later...

I hope it is oké that I post in this thread.

 

I'm on OS X 10.11.6 and 6.3.0-rc5. Recently I also noticed that it takes (very) long to open and list a folder with a lot of files using AFP (I prefer AFP over SMB). Not sure whether this is triggered by upgrading either OS?

 

I'd stay away from AFP because this is implemented in linux using a component called "netatalk".  This thing creates a database to do the CNID<->File mapping required for AFP protocol.  It's a bit picky and error prone if you don't know what is happening.  You probably are aware that Apple is phasing out AFP and moving to SMB in their own products.  In a future unRAID release, once TimeMachine via SMB is supported, we will probably deprecate AFP support and then eliminate it.

 

To speed up Finder listing of SMB shares you can add what is called "vfs_fruit" optimizations.  To do this in 6.2.4 and pre-6.3.0-rc6 releases, go to Settings/SMB and in the Samba extra configuration box, paste these lines:

 

ea support = yes
vfs objects = catia fruit streams_xattr
fruit:resource = file
fruit:metadata = netatalk
fruit:locking = none
fruit:encoding = native

 

Unfortunately once this is in place you will not be able to write to your 'flash' share via SMB because FAT file system does not have "ea" (extended attribute) support; but this is not something one normally does.  This is built-in properly in upcoming 6.3.0-rc6.

Link to comment

 

ea support = yes
vfs objects = catia fruit streams_xattr
fruit:resource = file
fruit:metadata = netatalk
fruit:locking = none
fruit:encoding = native

 

Unfortunately once this is in place you will not be able to write to your 'flash' share via SMB because FAT file system does not have "ea" (extended attribute) support; but this is not something one normally does.  This is built-in properly in upcoming 6.3.0-rc6.

 

Does this mean writing the boot device with SMB no longer works in 6.3?

Link to comment

 

ea support = yes
vfs objects = catia fruit streams_xattr
fruit:resource = file
fruit:metadata = netatalk
fruit:locking = none
fruit:encoding = native

 

Unfortunately once this is in place you will not be able to write to your 'flash' share via SMB because FAT file system does not have "ea" (extended attribute) support; but this is not something one normally does.  This is built-in properly in upcoming 6.3.0-rc6.

 

Does this mean writing the boot device with SMB no longer works in 6.3?

 

No, it means if you added those lines in 6.3-rc5 or below you can't write 'flash' share via SMB.  But 6.3-rc6 has been released now, so get rid of those lines and starting running -rc6.

Link to comment

FWIW, I have a couple of old Intel Macintoshes that can't be updated beyond OS X Lion (10.7). They work much better with AFP than SMB but I did make an adjustment to the Netatalk database that seems to make it more reliable.

 

In the unRAID webGUI, under Share Settings -> AFP Security I changed the location of the Volume dbpath to a folder on my cache pool, specifically /mnt/user/system/AppleDB.

 

Link to comment

FWIW, I have a couple of old Intel Macintoshes that can't be updated beyond OS X Lion (10.7). They work much better with AFP than SMB but I did make an adjustment to the Netatalk database that seems to make it more reliable.

 

In the unRAID webGUI, under Share Settings -> AFP Security I changed the location of the Volume dbpath to a folder on my cache pool, specifically /mnt/user/system/AppleDB.

Yes that is exactly the purpose of the "Volume dbpath" under a share AFP Security Settings.

Link to comment
  • 1 year later...

Looks like that VFS_FRUIT thing has been rolled into unRaid as of 6.5.0

 

This setting was under a specific user share, rather than the regular SMB Settings.

 

I dug up this old thread because I'm having problems connecting to my SMB shares via iOS 11.2.6, iPhone 7. Haven't solved it yet.

mainpage.png

Edited by dkerlee
Link to comment
  • 3 weeks later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.