This works for me. Except could it be,

"- if user shares are enabled, disk shares that are included in a current AFP user share can not be exported via AFP, and

"- if any disk shares are being exported via AFP, AFP user shares can not be enabled that include the existing AFP disk shares"

 

I.e., any particular disk may either be an AFP disk share or included in an AFP user share.

 

Why would you want to do this?  The way I see it, an unRaid server is typically set up in one of three "modes":

a) Only use disk shares, no user shares at all.

b) Only use user shares, no disk shares at all.

c) Use both, but only for the purpose creating new files via disk shares so that you have absolute control over which disks the files get created on, but for reading, you access through the user shares.

 

It's mode c) that is problematic with AFP.

 

Is there a mode d) ?

 

 

I use a disk share for backups and a user share for movies. They use distinct disks. Although if time machine starts working with users shares I may switch to user shares for backups.

Interesting reading on the subject of CNID's and netatalk:

http://netatalk.sourceforge.net/2.0/htmldocs/configuration.html#CNID-backends

 

The 2nd bullet point under "Note" (nesting volumes) is what's happening if disks involved in an AFP-exported user share are themselves also an AFP-exported disk share.

 

Also I don't understand the last bullet point that warns against exporting a share with both AFP and NFS.

I use a disk share for backups and a user share for movies. They use distinct disks. Although if time machine starts working with users shares I may switch to user shares for backups.

 

You could create a user share called "Backup" and restrict it to a specific disk or set of disks.

I hope it's OK that an inexperienced linux (but also Mac) user throws in 2 cents.

 

I use a disk share for backups and a user share for movies. They use distinct disks. Although if time machine starts working with users shares I may switch to user shares for backups.

 

You could create a user share called "Backup" and restrict it to a specific disk or set of disks.

 

Maybe because I recently transferred from other (out of the box) NAS platforms, but that is how I allocated my disks, so this would most definitely work for me. Would it still be possible to approach the individual disks with SMB?

Would it still be possible to approach the individual disks with SMB?

 

Yes.

I use a disk share for backups and a user share for movies. They use distinct disks. Although if time machine starts working with users shares I may switch to user shares for backups.

 

You could create a user share called "Backup" and restrict it to a specific disk or set of disks.

 

If you only allow AFP for user shares then anyone wishing to use AFP with a disk share could just create a user share which only uses the disk they want, much like you have said above.  Wouldn't this be fine?

This works for me. Except could it be,

"- if user shares are enabled, disk shares that are included in a current AFP user share can not be exported via AFP, and

"- if any disk shares are being exported via AFP, AFP user shares can not be enabled that include the existing AFP disk shares"

 

I.e., any particular disk may either be an AFP disk share or included in an AFP user share.

 

Why would you want to do this?  The way I see it, an unRaid server is typically set up in one of three "modes":

a) Only use disk shares, no user shares at all.

b) Only use user shares, no disk shares at all.

c) Use both, but only for the purpose creating new files via disk shares so that you have absolute control over which disks the files get created on, but for reading, you access through the user shares.

 

It's mode c) that is problematic with AFP.

 

Is there a mode d) ?

 

 

I use a disk share for backups and a user share for movies. They use distinct disks. Although if time machine starts working with users shares I may switch to user shares for backups.

 

I can work with only options a) and b). I just though that allowing an AFP disk share, if the disk is not included in any AFP share, adds more flexibility and does not violate the partially overlapping AFP shares constraint. AFP disk shares would have to be created on a per disk basis. If this delays the AFP release then add it to the maybe-to-do list.

 

Allowing per-disk disk shares for all protocols could be a feature request.

 

Using disk shares allows one to avoid the performance penalty of FUSE.

I can work with only options a) and b). I just though that allowing an AFP disk share, if the disk is not included in any AFP share, adds more flexibility and does not violate the partially overlapping AFP shares constraint. AFP disk shares would have to be created on a per disk basis. If this delays the AFP release then add it to the maybe-to-do list.

 

Allowing per-disk disk shares for all protocols could be a feature request.

 

There is a new per-disk config variable that says, "Let disk participate in User Shares [Yes or No]".  If set to No, then the disk is never considered in user share file system.  This was created, ironically enough, to set up a dedicated disk share for backup purposes.  But what I can do is, if this variable is set to No, then allow an AFP disk share export.  If later you try to set variable to Yes, but system notices disk is exported via AFP, it won't let you.

 

Using disk shares allows one to avoid the performance penalty of FUSE.

Understood.  Supposedly the latest version of FUSE has a "zero copy" feature where file data doesn't have to make a traversal through user space.  I haven't had a chance to try this yet though.

Hi,

 

I've been using Unraid w/Netatalk 2.0.5, CNID 'dbd' and user shares for a few months, I haven't had any problems with a "movies" share.

 

There is also a "TimeMachine" share that spans a few disks. TimeMachine will do everything it can to fill a drive/share to the max. This would eventually corrupt the CNID database.

 

The question I have is when Beta 3 w/ AFP is out, will you be compensating for CNID database corruption when a share is filled?

 

Here's the excerpt from the Netatalk website

 

http://netatalk.sourceforge.net/2.0/htmldocs/configuration.html#CNID-backends

 

notes:

"If there's no more space on the filesystem left, the database will get corrupted. You can work around this by either using the -dbpath option and put the database files into another location or, if you use quotas, make sure the .AppleDB folder is owned by a user/group without a quota."

 

I manually entered a minimum of 2gb free space in one of the share options, but haven't had a chance to test it yet. Either way I would prefer something built in to compensate for it if you have time.

 

BTW, Unraid is great

Thanks

4. Initial release is based on netatalk 2.0.5, is there any compelling reason to move to 2.1?

 

Well, I'm definitely not an AFP expert in any way but there is one reason you might consider moving to the latest stable version of Netatalk sometime soon.  I'm a current ReadyNAS user thinking about making the switch to unRAID.  Snow Leopard differs from previous versions of OS X because of its increased usage of extended attributes.  One example - every time you download a file the OS knows that it was downloaded, what program downloaded it, and when.  All of that information is kept in extended attributes.  The Netatalk folks did not start supporting these attributes until 2.1 (http://netatalk.sourceforge.net/2.1/ReleaseNotes2.1.html), so people using Snow Leopard with any NAS that had an earlier version of Netatalk had issues with file copies.  Check out http://discussions.apple.com/thread.jspa?threadID=2133809&tstart=0 for more details, and here's another link which discusses ReadyNAS issues supporting Time Machine on Netatalk 2.0.5: http://www.readynas.com/forum/viewtopic.php?f=71&t=32767&start=0&hilit=netatalk+2.1.  If your test rig is Leopard, you would not have run into these issues.  My two cents, hope it helps....

4. Initial release is based on netatalk 2.0.5, is there any compelling reason to move to 2.1?

 

Well, I'm definitely not an AFP expert in any way but there is one reason you might consider moving to the latest stable version of Netatalk sometime soon.  I'm a current ReadyNAS user thinking about making the switch to unRAID.  Snow Leopard differs from previous versions of OS X because of its increased usage of extended attributes.  One example - every time you download a file the OS knows that it was downloaded, what program downloaded it, and when.  All of that information is kept in extended attributes.  The Netatalk folks did not start supporting these attributes until 2.1 (http://netatalk.sourceforge.net/2.1/ReleaseNotes2.1.html), so people using Snow Leopard with any NAS that had an earlier version of Netatalk had issues with file copies.  Check out http://discussions.apple.com/thread.jspa?threadID=2133809&tstart=0 for more details, and here's another link which discusses ReadyNAS issues supporting Time Machine on Netatalk 2.0.5: http://www.readynas.com/forum/viewtopic.php?f=71&t=32767&start=0&hilit=netatalk+2.1.  If your test rig is Leopard, you would not have run into these issues.  My two cents, hope it helps....

 

Thanks!  I'll look into this.

Just migrated to 5. Mac household, happy to help you test AFP if needed.