[Samba] Again on NT ACLs and Samba re-share of NFS or SMB mount

[Gaiseric Vandal]

If your goal is to move data to a new server, then any proxy solution 
may be problem because  you may need to keep the old server as a front 
end  even after all the data is moved over (especially if you use iscsi)


Assuming that you do want to keep both servers, and If both servers are 
in close proximity to each other,   then ISCSI may be an option, 
assuming you are OK keeping the first server in place. It does in fact 
give you the great convenience of not having to set up a 2nd domain 
controller-   from the user perspective it is the same server.  From the 
admin perspective, you don't have to worry about  keeping permissions in 
sync between systems.    I would, however, still recommend adding 
dedicated network cards (if necessary) and purchasing a separate gigabit 
ethernet switch(es) to segment your iscsi traffic.     Neither should  
be expensive.



However, if you want to eventually shutdown the first server, the best  
solution for a migration may  to configure your new server as a backup 
domain controller (assuming the existing server is the primary domain 
controller.)    then you can use DFS, and login scripts and even samba 
reshares of nfs as you move data from one server to another.        You 
can move user home directories from one server to another after hours 
and then update login script or user account parameters so that the 
users don't even notice a change.


Having multiple domain controllers works best if you have an LDAP 
backend.     If not you can probably copy the account TDB files from one 
server to another-   they will get out of sync tho so this is not a good 
long term solution.  But in the end, you can shutdown the old server and 
you have a simple solution to manage.    Long term, if you have multiple 
domain controllers the LDAP backend is the way to go.



I have tried setting up an server with an iscsi share, then remounting 
it locally back to itself.  THe system was an iscsi client of itself.   
it didn't work out very well.


I am not 100% sure on the NFS v4 and samba reshares.     I have not run 
into corruption problems with resharing  NFS files with samba.  However, 
I don't think  I had issues where a Windows user and a Linux user would 
both open the same file at the same time.        I use solaris 10, but I 
some point I transitioned from UFS file servers to ZFS file systems.     
I believe UFS was posix while ZFS is actually more compatible with NFS 
v4 ACL's. I did run into some issues with Office 2007 documents not 
setting file permissions properly and then loosing some documents until 
the folder permissions were set correctly.  Not really an NFS issues but 
it does make me a cautious about adding any more layers of file sharing 
that is necessary.




On 07/31/14 14:19, Gionatan Danti wrote:
> Il 2014-07-31 16:11 Gaiseric Vandal ha scritto:
>> What is the higher level goal-   I mean why to you want to reshare the
>> samba share instead of having the users access it directly? Is the
>> remote server part of the same domain?
>
> The goal is to trasparently move the older files to another server, 
> with more (and cheaper) storage.

>
>> When resharing a samba mount, your proxy machine is then rewriting the
>> files, I am not suprised that they are owned by root.
>
> But when writing locally, the SAMBA server can set user/group 
> correctly. Why it can't do the same on a remote SMB share?
>
>> I think
>> configuring a DFS redirect from the proxy server to the remote server
>> would be simpler.  That does mean that the users ARE in fact accessing
>> the remote server but it will appear to them that they are accessing
>> the local server.     that does require that you have consistent user
>> ids on both machines.  Which may be   why you want to avoid users
>> accessing directly.
>
> DFS was evaluated as the first choice, but my customer want to move 
> single, specific files and not entire directories. From what I know, 
> Samba's DFS is a directory-level affair (with the use of "custom" 
> symlinks).
>
>> I have used samba to reshare NFS directories.  In this case both
>> servers were on the same LAN.     Both servers had a command account
>> backend for unix user id's.   So it generally worked ok EXCEPT if the
>> user was in more than 16 groups.  That would cause users to get denied
>> access to some directories.  This was with Solaris 10 servers so I
>> think NFS v4 wd have been the default.
>
> Interesting... your base directory was accessed via SMB and NFS at the 
> same time? Did you ever experience corruptions? Anyway, To preserve 
> ACLs via POSIX remapping, it seems that I need to use NFSv3 
> (questions: is the NFSv4-style ACLs VFS module ready? Can be used with 
> Samba 3.x?).
>
>> Re iSCSI-  you would be creating iscsi "file"   on the remote machine
>> and mounting as a disk drive on the proxy machine.  Any application on
>> the proxy machine would think it was a local drive.   So you don't
>> have any issues about file permissions or owners.         With iscsi,
>> you are not simply sharing an existing directory on the server the
>> same way you share via NFS or Samba or other file sharing protocol.
>>     The iscsi server can not access files on an iscsi share, unless it
>> is configured to be an iscsi client of itself.          I think the
>> only reason you might want to use ISCSI over a remote link is for
>> disaster recovery preparedness -  e.g. your local server syncs a copy
>> of local  data to a remote site.    ISCSI practices generally
>> recommend that iscsi traffic is on a separate LAN or VLAN from file
>> traffic. You also have to deal with iSCSI security (e.g. CHAP
>> authentication.)        I would also be concerned that you would have
>> poor performance accessing iSCSI over a  remote connection for
>> production use.      A local SAS drive has a 3 Gbit/sec or 6Gbit/sec
>> interface.    (In reality the disk i/o would probably be less) which
>> is why you would use a Gbit network for iSCSI traffic on the LAN.
>>  I would worry about race conditions when the OS starts hammering a
>> slow "disk" as write requests fail and get retried.
>
> Yes, I know the limitations (or better, the design goals) of iSCSI. I 
> wonder that, if all else fail, I can use it with a similar setup to 
> your. Thank for reporting!
>
>> FYI -  I do use iscsi with my samba and nfs servers.  But I have
>> dedicated 1 Gbit switches, a commercial SAN appliance, and the servers
>> and SAN are all in the same closet.
>
> Oh, I'm confined to more pedestrian (and cheaper!) hardware.
>
> Thank you very much.
>
>>
>>
>>
>>
>> On 07/31/14 03:24, Gionatan Danti wrote:
>>> Hi all,
>>> I spent the past days reading the mailing list archive, but still I 
>>> have some questions to ask. Moreover, a detailed report of what I 
>>> attempted can be useful for others.
>>>
>>> Goal: having a remote SMB or NFS share, mount it locally and 
>>> re-share it using SAMBA. The remote SMB/NFS share will _not_ be 
>>> directly used by users; it will be used only through the local samba 
>>> "proxy". NT ACLs should be preserved as close as possible.
>>>
>>> Software version: both machine runs CentOS 6.5 X86_64, with kernel 
>>> 2.32.x and samba version 3.6.x
>>>
>>> I evaluated the following possibilities:
>>>
>>> 1) use mount.cifs with root user to mount the remote share locally, 
>>> then re-export it via Samba.
>>> PRO:  use of the same protocol (SMB); support for POSIX ACLs
>>> CONS: when creating some files using a Windows client connecting to 
>>> the Samba server, the file's owner is not set correctly as all new 
>>> files are owned by root and not by the Windows user.
>>> QUESTION 1: It is possible to use a CIFS mount and correctly assing 
>>> owners to new files? Why it does not work? I am missing something?
>>>
>>> 2) use mount.nfs4 (NFS vers. 4) to mount the remote share (via NFS 
>>> of course), the re-export it via Samba.
>>> PRO: NFSv4 has excellent performances; NFV4 ACLs support
>>> CONS: no POSIX ACLs support; no USER_XATTR support
>>> QUESTION 2: the missing POSIX ACLs support prevents to replicate NT 
>>> ACLs and at the same time the missing USER_XATTR prevents to use the 
>>> security.NTACL EA to store ACLs. On the mailing list I read about a 
>>> NFSv4 VFS module. However, I can not find it anywhere. It is still 
>>> developped? Can samba use NFSv4 ACLs?
>>>
>>> 3) use mount.nfs ver. 3 to mount the remote share (via NFS of 
>>> course), the re-export it via Samba.
>>> PRO: NFSv3 supports POSIX ACLs
>>> CONS: two different protocols to use/configure, I need to disable 
>>> strict locking in Samba configuration, NFSv3 is an old protocol 
>>> nowadays.
>>> QUESTION3: using the NFS share via Samba _only_ (even with strict 
>>> locking=no) is a reasonable setup or I can expect data corruption? 
>>> The NFS share will _never_ accessed directly.
>>>
>>> 4) use iSCSI (or similar protocol) to export the remote disk using a 
>>> low-level protocol and mount it locally on the samba server.
>>> PRO: the server directly mounts an EXT4 filesystem, with POSIX ACLs 
>>> and USER_XATTR (enabling perfect store of Windows ACLs)
>>> CONS: it effectively "stole" the disk from the remote server; 
>>> potentially lower performance (?)
>>> QUESTION 4: anyone used samba via iSCSI? Did you have good performance?
>>>
>>> My current testing setup is using proposal n.3 - NFSv3
>>> I both have good performance and good ACLs mapping, but I'm open to 
>>> suggestions
>>>
>>> Thank you all.
>>>
>