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

Gaiseric Vandal gaiseric.vandal at gmail.com
Thu Jul 31 08:11:11 MDT 2014


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?


When resharing a samba mount, your proxy machine is then rewriting the 
files, I am not suprised that they are owned by root.      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.


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.

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.



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.






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.
>



More information about the samba mailing list