SMB | how to not present SMB shares on OSX shares dialog, when an user has not access rights to a particular share

    Hello


    I am new to the OMV and I am evaluating it as an replacement for a long-time MacOSX Server installation. Thus far it was really easy to configure on OMV the Netatalk and SMB services for combined use on the same shared folders - many thanks for bringing OMV to the community.



    As some user-groups have/should have access only to particular shares, it would be nice if on a SAMBA client connection (from MacOSX share dialogue / Got To Server) those shares that an user-groups has no access rights would not be displayed and thus not selectable. Actually this works with AFP-connections, but with the SMB-connection all shares are displayed and connection to the shares without access rights fail to mount with an error message. Is there any SMB setting that allows this behaviour (setting the shared folders privileges to "No Access" is not possible as it disturbs correct Netatalk working?



    I am sorry if this configuration questions has been already posted elsewhere.



    Many thanks in advance for any hint




    P.S. to explain by an example:


    I have three shares (share00 .. 20) and an user group grp20. grp20 is allowed to access the shares as followed:


    share00 | grp00
    share10 | grp10, grp20
    share20 | grp20


    thus to grp20 only share10 and share20 should be shown. This is the case with AFP but not with SMB, where all 3 shares are present. If an user of grp20 is selecting all 3 shares on the list, the connection attempt terminates with an error message and no share is mounted at all.

    Unfortunately OMV allows to share the same data with both SMB and AFP at the same time which is not a great idea: https://redmine.ixsystems.com/issues/5904


    This is not an issue if your server is OS X 10.8 or later since Apple does all the 'translation' stuff in the background and it makes no difference whether you're accessing your data via SMB or AFP today and vice versa tomorrow. But this is an issue with most if not all other filesharing solutions.


    So please take care and decide whether you want to choose AFP or SMB (SMB is the future since AFP is deprecated for many good reasons).

    Hello


    Many thanks for your answer and I am sorry for my delay to replay.


    I appreciate very much your comment about the issues and your hint to the FreeNAS forum where the issues are discussed in detail.


    On my opinion it is a "fortune" that OMV does provide AFP and SMB shares on the basis of the same folders/directory-structure. And OMV does it very well. I have evaluated many commercial and free NAS and found only OMV (free) and Open-e (commercial), that do combined AFP/SMB share very well. I gave twice a try to FreeNAS (also to the latest version) and it could not convince me (also by binding it to Apple Open Directory LDAP).


    Actually we will go as long as possible with AFP this protocol outperforms significantly over SMB on all NAS I have evaluated (even when on the MacOSX client and server side encryption is disabled). There would be no reason to us to switch away from MacOSX server (also if the future of it is always uncertain), but we have since MacOSX 10.11 (we are actually on 10.12 for the server) "permission glitches" accessing it by AFP from MacOSX clients. But the issue is not AFP but MacOSX Finder/File-Index (on the server side) that blocks temporally files for indexing and building file previews.


    For user (MacOSX Server user Network-Accounts) we had to switch from AFP to SMB, as we found that several Apple base apps like iTunes do not correctly work (in the case of iTunes backups are impossible), if the user Network-Accounts are not based on SMB.


    Thus we can live with those "little" SMB issues on combined AFP/SMB on OMV as SMB access on these combined shares are rare cases and for MacOSX mobile users Network-Accounts will be only SMB (unfortunately).


    Hopping the performance shortcomings of SMB on MacOSX will be sometimes in the future solved or an other new high performance network file protocol will arise.



    With best regards,


    André

    Zitat von relume

    your hint to the FreeNAS forum where the issues are discussed in detail

    https://redmine.ixsystems.com/issues/5904 isn't a forum discussion but a FreeNAS feature request back from 2014 outlining the underlying problems and trying to raise awareness for the issues and how to solve them. I discussed similar issues already with Janusz Bak (Open-E CTO).

    Zitat von relume

    I have evaluated many commercial and free NAS and found only OMV (free) and Open-e (commercial), that do combined AFP/SMB share very well

    I have to disagree here since the only 'products' known to me that are usable today and flawlessly allow for using AFP and SMB at the same time are OS X (Server) starting with 10.8 and Helios EtherShare/PCshare (but both require macOS client versions 10.7 or above for SMB access since otherwise macOS uses ._ files for metadata and not alternate data streams). The issues with other solutions are always the same: encoding troubles, metadata representation (loosing access to Windows file streams or resource forks/EA) and CNID inconsistency.

    Zitat von relume

    Actually we will go as long as possible with AFP this protocol outperforms significantly over SMB on all NAS I have evaluated (even when on the MacOSX client and server side encryption is disabled)

    To me it seems not encryption is the problem but packet signing (you could try to set signing_required=yes in /etc/nsmb.conf). With no packet signing SMB performance seems quite reasonable to me: https://github.com/openmediava…01#issuecomment-468270197

    To elaborate on why it's not a good idea to mix SMB and AFP access at the same time. I have one directory here on OMV4 shared by both Samba and Netatalk. Mounting via AFP, creating one dir called "AFP" and then copying three files in it. Unmount the share, remount with SMB, creating one dir called "SMB" and copying the same 3 files in it.


    Looks like this in the beginning when mounting again with AFP and looking into the AFP folder:


    On the server it looks like this:



    Please note that there are 3 files less in the AFP folder since with Netatalk/AFP file(system) metadata wasn't stored in additional ._ files but in extended attributes:


    That's how this stuff is stored when accessing via AFP (since Netatalk uses EAs if the underlying filesystem supports it):

    Code
    John@RockPro64:/sharedfolders/SAMBA_BTRFS$ getfattr -d -m ".*" AFP/Etcher.app/
# file: AFP/Etcher.app/
user.com.apple.quarantine="01c3;5bb09ec4;Safari;C22D7C55-0F3B-49B5-BE59-3C8A896156F6"
user.org.netatalk.Metadata=0sAAUWBwACAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAEAAAAmgAAAAAAAAAIAAABYgAAABAAAAAJAAAAegAAACAAAAAOAAABcgAAAASAREVWAAABdgAAAAiASU5PAAABfgAAAAiAU1lOAAABhgAAAAiAU1Z+AAABjgAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAInTJhSJ0yYWAAAAAJH5bAQAAAAArAAAAAAAAAANTAAAAAAAALZ7rXAAAAACrAQAA

    And when using SMB with OMV defaults you end up with another location:

    Code
    John@RockPro64:/sharedfolders/SAMBA_BTRFS$ strings SMB/._Etcher.app 
Mac OS X        
ATTR
com.apple.quarantine
01c3;5bb09ec4;Safari;C22D7C55-0F3B-49B5-BE59-3C8A896156F6
This resource fork intentionally left blank

    You could try to solve this issue by configuring Samba to use file streams as well but with different macOS client versions this still won't work in all combinations. Also when accessing files via Samba, then Netatalk's CNID databases will not be updated and next access via AFP can result in directory contents not displayed at all.


    At least no encoding issues with this specific setup (I switched to the server and piped the ls -d output for both directories through hexdump -C:


    Code
    00000000  41 46 50 2f 54 65 73 74  20 61 c3 a4 c3 bc c3 b6  |AFP/Test a......|
00000010  c3 9f 20 ef 80 a2 ef 80  a7 ef 80 a6 5e ef 80 a1  |.. .........^...|
00000020  2e 61 70 70 2f 0a                                 |.app/.|
00000000  53 4d 42 2f 54 65 73 74  20 61 c3 a4 c3 bc c3 b6  |SMB/Test a......|
00000010  c3 9f 20 ef 80 a2 ef 80  a7 ef 80 a6 5e ef 80 a1  |.. .........^...|
00000020  2e 61 70 70 2f 0a                                 |.app/.|

    But Netatalk is configured by default to use unix charset = LOCALE which in my case results in matching behavior with what Samba uses. On other systems this can differ and then you also run into an encoding nightmare with cross protocol usage.


    TL;DR: accessing same data on OMV shares with both AFP and SMB at the same time will cause various issues. AFP will be gone with OMV5 anyway. So choose wisely.

    Hello


    Many thanks again! I appreciate very much your time and effort to clarify further the possible issues. I was not aware of those deeper issues, as my evaluations where on the surface (performance, basic sharing and permissions handling and open ldap integration and some file/app tests). Also many thanks about the future of AFP in OMV5.


    best regards,


    André

    Zitat von relume

    many thanks about the future of AFP in OMV5

    Well, AFP is deprecated since a long time. According to the Helios CEO they told developers at an WWDC session already two years prior to the announcement that they will stop supporting AFP in the future. If (lacking) TimeMachine support for SMB hadn't been an issue I guess they would've already removed AFP from macOS client.


    For me personally 2019 is the year to seriously evaluate a switch to SMB/Samba since AFP being removed from macOS clients becomes a real concern now. So far it looks pretty fine, especially since OMV5 already uses the various Samba tweaks necessary for macOS SMB clients.

    I meant "Also many thanks [for your hint] about the [no] future of AFP in OMV5" :) (this has a "slightly" different meaning)

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden