What is the easiest way to move share to another pool?

manxam

Active Member
Jul 25, 2015
233
49
28
Hi, I tried this once before but it ended up more manual than I'd like and was hoping that someone could post an easy way to accomplish this via CLI (omnios) or Napp-iT.

I have a pool "ssd1" and a zfs volume "Users" shared using cifs by the name "Users"
I'd like to move this entire volume to another pool while keeping the share name the same.

Aside from creating a new volume on the new pool, copying the files, renaming the old share, and creating a new share, is there any easier way to accomplish this?

This share is used for windows folder redirection so minimal "screwing around" is preferred.

For some reason I keep getting lost when attempting zfs send/recv, etc.

Any assistance would be greatly appreciated.

Thanks,
M
 

gea

Well-Known Member
Dec 31, 2010
2,500
842
113
DE
For some reason I keep getting lost when attempting zfs send/recv, etc.
Thanks,
M
zfs send/ replicate is the preferred method
If you use napp-it, create a replication job ex
/ssd1/Users-> /pool2 to duplicate a filesystem to /pool2/Users

then delete the job, set the new filesystem to rw
and when everything is ok, delete the old filesystem

The share property and sharename is copied so you must at least disable the share on the first pool.
 
  • Like
Reactions: gigatexal

manxam

Active Member
Jul 25, 2015
233
49
28
Thanks Gea, I believe my past issue was due to the sharename being duplicated. I will disable the existing share first, replicate, set rw, and then enable the share on the new fs.
 

manxam

Active Member
Jul 25, 2015
233
49
28
@gea, I'm finally getting around to performing this but notice that, using Napp-it, ACLs and compression don't come across when using the replication menu. Is there a way to force these to sync? As this is a user folder relocation share for Windows I'd prefer not to have to reconfigure ACL on the new/replicated share. Also, compression is disabled by default and this pool contains mostly compressible data so the replicated size is larger than the original.

Thanks,
M
 

gea

Well-Known Member
Dec 31, 2010
2,500
842
113
DE
This is related to how replication with zfs send works.
- only some filesystems properties are kept.
- all file properties like ACL are kept

Regarding compress
If you want to keep lz4 compress, you must enable lz4 on the new parent filesystem.
Due the property inheritance the replicated filesystem will be compressed.

Such a behaviour is wanted/ needed to allow a replication between filesystem where a feature is not available or to compress/ uncompress a filesystem with a replication.


Regarding ACLs
As said, they are replicated but to understand you must compare to Windows as Solaris CIFS behaves mostly like Windows.

On a workgroup

- If you remove a disk from one Windows PC and add it to another, all Windows credidentials/ SID references are unknown. You must reset/ set all ACLs newly.

This is similar on Solaris in workgroup mode.
If you keep all Unix user and Unix uid/gid identical it should work to keep the ACL workable

On an Active Directory Domain if both machines are a domainmember
- If you remove a disk from one Windows PC and add it to another, all Windows credidentials/ SID references are kept.

This is similar to Solarish in domain mode when you move a pool or replicate a filesystem.
All domainbased ACL are working as the Windows SIDs are stored with the file.
This is usually an NTFS feature and unique for a Unix filesystem like ZFS and only available for Solarish CIFS, not for SAMBA.
 
Last edited:

manxam

Active Member
Jul 25, 2015
233
49
28
@gea: Thanks again for the detailed reply but it appears that the ACL's aren't working as you stated.
I have deleted the replicated volume, snapshots, and replica set and tried again.
In the first I have specific ACLs configured in Windows for the folders (not share perms) and the replicated file permissions are defaulted back to administrator only. Missing creator owner, specific groups, etc as in the original volume.

Am I missing something here?

EDIT: this server is joined to the domain.
 
Last edited:

gea

Well-Known Member
Dec 31, 2010
2,500
842
113
DE
Backup domain data is something that I do on a daily base without problems. No need to care about any setting to keep permissions intact. The only setting that comes to mind that may result in ACL problems may be the zfs property aclinherit that must be set to pass-through for a Windows alike behaviour and manual idmapping that should be used only for a setting like domainadmin=root not for regular users as this will result in a root ACL for the Windows user.
 

dragonme

Active Member
Apr 12, 2016
282
28
28
Send receive is obviously a neat zfs feature.. its powerful but also has limitations.. it needs synced snapshots, it only works on zfs file systems or pools.. not sub folders ....

I use syncovery for those times where send/rcv is impractical or impossible ....