Napp-it share to ESXi, Apple, Windows...

[bmacklin]

I have Napp-it + ESXi 5.1 configured.

I mapped RDM drives and it seems to work fine in Napp-it

I created my raidz pool called, zpool, and enabled sharesmb and sharenfs properties on it.

I used zfs create to make a "folder" /zpool/vmstore for share back to ESXi for all the virtual machine images.

I added a user to the "local user with SMB password"
I added that user to the group "power users"

An idmapping from wingroup@power users to unix:staff was automatically created for me.

When I tried SMB mount from windows using the username and password, I can read and write.
If I do this on mac, I can only read. Write gives me an error (unless I use root)

If I try to mount /zpool/vmstore via ESXi, I can see that it is mounted, but I cannot modify the drive.

• 
  What can I do to make SMB read/write possible while not using the root account (in OS X)?

• 
  What can I do to make NFS mounts read and write in ESXi?

• 
  How to configure Apple share?

 

[bmacklin]

I have Napp-it + ESXi 5.1 configured.

I mapped RDM drives and it seems to work fine in Napp-it

I created my raidz pool called, zpool, and enabled sharesmb and sharenfs properties on it.

I used zfs create to make a "folder" /zpool/vmstore for share back to ESXi for all the virtual machine images.

I added a user to the "local user with SMB password"
I added that user to the group "power users"

An idmapping from wingroup@power users to unix:staff was automatically created for me.

When I tried SMB mount from windows using the username and password, I can read and write.
If I do this on mac, I can only read. Write gives me an error (unless I use root)

If I try to mount /zpool/vmstore via ESXi, I can see that it is mounted, but I cannot modify the drive.

• 
  What can I do to make SMB read/write possible while not using the root account (in OS X)?

• 
  What can I do to make NFS mounts read and write in ESXi?

• 
  How to configure Apple share?

Update: I installed AFP and found some afp.conf files online which I used. While I can connect to the share, I still cannot write to the share.

/etc/afp.conf

[Global]
mimic model = TimeCapsule6,106
log level = default:warn
log file = /var/log/afpd.log
hosts allow = 192.168.1.0/16

[Homes]
basedir regex = /home

[TimeMachine]
path = /zpool/tm_backup
valid users = tmuser
time machine = yes

[Shared Media]
path = /zpool
valid users = joe

 

[gea]

This can be a combinatione of permissions and settings

- Lets start with proper defaults for ESXi (NFS)
- set ZFS properties of /zpool/vmstore to
aclmode to restricted (ignore Unix chmod) or passthrough
aclinherit to passthrough

reset acl of /zpool/vmstore to everyone@=modify recursively
(menu zfs filesystems > folder ACL > reset ACL)

Set nbmand to on (good for SMB+NFS, hinders AFP to work)

ESXi should work now, as well as SMB from Win and Mac's
when using Finder - Goto - Connect to server - smb://serverip
or nfs://serverip for NFS

regarding NFS: there is no user authentication with NFS3
so best is, using everyone@ permissions for NFS shares.
NFS is based on a good-will based on host ip where Solaris/Windows/
ESXi/ Apple behaves different regarding used UID credidentials

Check idmappings:
do not add any user mappings without domains
group mappings SMB groups > Unix groups are ok


2. AFP
create a ZFS filesystem like /zpool/macfiles
set ZFS properties to aclmode AND aclinherit to passthrough
set nbmand to off
AFP share with menu ZFS filesystems > click to off under AFP
connect using Finder - Goto - Connect to server - afp://serverip

 

[bmacklin]

This can be a combinatione of permissions and settings

- Lets start with proper defaults for ESXi (NFS)
- set ZFS properties of /zpool/vmstore to
aclmode to restricted (ignore Unix chmod) or passthrough
aclinherit to passthrough

reset acl of /zpool/vmstore to everyone@=modify recursively
(menu zfs filesystems > folder ACL > reset ACL)

Set nbmand to on (good for SMB+NFS, hinders AFP to work)

ESXi should work now, as well as SMB from Win and Mac's
when using Finder - Goto - Connect to server - smb://serverip
or nfs://serverip for NFS

regarding NFS: there is no user authentication with NFS3
so best is, using everyone@ permissions for NFS shares.
NFS is based on a good-will based on host ip where Solaris/Windows/
ESXi/ Apple behaves different regarding used UID credidentials

Thank you so much! This has allowed esxi to write to the vmstore mount!

Everything regarding zpool/vmstore is now working - I can write to it via SMB from OS X.

I still cannot write to any other vdev though. Should I apply the steps you gave me everywhere? Also, since nbmand should be off for AFP shares, this means that I shouldn't use AFP in OSX, or that I need to keep the data from OSX separate from the data elsewhere?

 

[gea]

While you can build a multiprotocol server with AFP (the Apple style filesharing), NFS (traditional Linux/Unix filesharing) and SMB (Windows alike filesharing) you must know and accept that they are highly incompatible in some aspects.

Example.
NFS3 does not know any user identification. All is based on host ip on a good will base. Every platform/OS handles permissions different

AFP is more Unix alike and based on user identification and Unix user id's (UID). It is ACL aware but cannot modify them. It neeeds special permissions and settings on shares and a database to hold file id's

SMB on Solaris CIFS (Samba acts different and does not use Windows SID) is like Windows. It can use the original Windows Security id's (SID). This is unique in the Unix/Linux world as it allows to move pools between servers that are members of the domain without loosing access credentials (permissions stay intact). This behaviour is otherwise only available with Windows and NTFS. Some problems remain like idmapping between Windows SID and Unix UID/GID as ZFS is a Unix filesystem despite the additional use of Windows SID as extended ZFS attributes.

To overcome this, you should either divide your files/shares based on the protocol or you must try to find a way to acces that covers all protocoll needs - mostly by reducing it to a everyone@=allow

Since Apple is moving to SMB as the default protocol in OSX 10.9 and Linux/Unix can use SMB without problems, SMB is the protocol of choice now for all platform (beside high performance usage like with ESXi or Macs and video editing as an AFP alternative)

Remaining problem:
Current Mac's are quite slow with SMB (hope Apple can fix this weakness since they replaced Samba in OSX with their own SMB stack).

Current Mac's need AFP only for timemachine (I do not care, I prefer Carbon Copy Cloner for system images and the rest is on ZFS)

 

[bmacklin]

While you can build a multiprotocol server with AFP (the Apple style filesharing), NFS (traditional Linux/Unix filesharing) and SMB (Windows alike filesharing) you must know and accept that they are highly incompatible in some aspects.

Example.
NFS3 does not know any user identification. All is based on host ip on a good will base. Every platform/OS handles permissions different

AFP is more Unix alike and based on user identification and Unix user id's (UID). It is ACL aware but cannot modify them. It neeeds special permissions and settings on shares and a database to hold file id's

SMB on Solaris CIFS (Samba acts different and does not use Windows SID) is like Windows. It can use the original Windows Security id's (SID). This is unique in the Unix/Linux world as it allows to move pools between servers that are members of the domain without loosing access credentials (permissions stay intact). This behaviour is otherwise only available with Windows and NTFS. Some problems remain like idmapping between Windows SID and Unix UID/GID as ZFS is a Unix filesystem despite the additional use of Windows SID as extended ZFS attributes.

To overcome this, you should either divide your files/shares based on the protocol or you must try to find a way to acces that covers all protocoll needs - mostly by reducing it to a everyone@=allow

Since Apple is moving to SMB as the default protocol in OSX 10.9 and Linux/Unix can use SMB without problems, SMB is the protocol of choice now for all platform (beside high performance usage like with ESXi or Macs and video editing as an AFP alternative)

Remaining problem:
Current Mac's are quite slow with SMB (hope Apple can fix this weakness since they replaced Samba in OSX with their own SMB stack).

Current Mac's need AFP only for timemachine (I do not care, I prefer Carbon Copy Cloner for system images and the rest is on ZFS)

Thanks gea. I noticed AFP writes to my Napp-it at about 45mb/s and SMB writes at ~20mb/s. I get weird permission errors when I transfer using AFP. This is a shame. I hope future updates will change this.