specific share not accessible, others working fine, after point release upgrade - Samba

This is a discussion on specific share not accessible, others working fine, after point release upgrade - Samba ; I've got a strange situation where sharing a particular directory as follows is not accesible: [staging] path = /webdev/staging writeable = yes create mask = 664 directory mask = 775 valid users = +ABCCORP+webdevstaging force group = ABCCORP+webdevstaging # file ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: specific share not accessible, others working fine, after point release upgrade

  1. specific share not accessible, others working fine, after point release upgrade

    I've got a strange situation where sharing a particular directory as
    follows is not accesible:
    [staging]
    path = /webdev/staging
    writeable = yes
    create mask = 664
    directory mask = 775
    valid users = +ABCCORP+webdevstaging
    force group = ABCCORP+webdevstaging
    # file permission lockdown
    create mode = 775
    force create mode = 775
    security mask = 0775
    force security mode = 0775
    # directory permission lockdown
    directory mode = 775
    force directory mode = 775
    directory security mask = 0755
    force directory security mode = 0755

    This share works fine:
    [testshare]
    path = /webdev/staging
    writeable = yes
    create mask = 664
    directory mask = 775
    valid users = +ABCCORP+webdevstaging
    force group = ABCCORP+webdevstaging
    # file permission lockdown
    create mode = 775
    force create mode = 775
    security mask = 0775
    force security mode = 0775
    # directory permission lockdown
    directory mode = 775
    force directory mode = 775
    directory security mask = 0775
    force directory security mode = 0775

    I think it broke when I updated Samba on Fedora Core 5 from
    3.0.23c-1.fc5 to 3.0.24-4.fc5. I've tried any number of things short
    of rebooting the Samba server.

    It seems as if there's something cached or corrupted somewhere, but
    I'm stumped. Does anyone have any suggestions? I have debug level 10
    logs of what's happening that I can include. My smb.conf is below with
    a couple things redacted. The 'root' share and the 'development' share
    both work fine. So does the 'testshare' share, as I said above. I
    tried all the standard troubleshooting with wbinfo, kinit, and getent
    and they all seem to be returning the correct results.
    #======================= Global Settings
    =====================================
    [global]
    workgroup = abccorp
    netbios name = abc-staging
    server string = ""
    wins server = 10.10.10.205

    log level = 10
    log file = /var/log/samba/%m.log
    max log size = 5000
    socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192

    host msdfs = no
    load printers = no
    # Removed for Domain
    ; username map = /etc/samba/smbusers
    # Added for Domain member config
    realm =
    security = ADS
    password server = *
    preferred master = no
    winbind separator = +
    winbind enum groups = yes
    winbind enum users = yes
    idmap uid = 10000-20000
    idmap gid = 10000-20000

    #============================ Share Definitions
    ==============================
    # admin share for my use only, delete this if doesn't work here
    and it's still here for some reason
    [root]
    path = /
    writeable = yes
    browseable = no
    force user = root
    create mask = 775
    directory mask = 775
    valid users = ABCCORP+
    force group = ABCCORP+webdevstaging

    # staging share points to a directory that is accessable by all
    # members of the webdev group, creates and directory masks force
    # g+w on all files and g+wx on all directories
    [staging]
    path = /webdev/staging
    writeable = yes
    create mask = 664
    directory mask = 775
    valid users = +ABCCORP+webdevstaging
    force group = ABCCORP+webdevstaging
    # file permission lockdown
    create mode = 775
    force create mode = 775
    security mask = 0775
    force security mode = 0775
    # directory permission lockdown
    directory mode = 775
    force directory mode = 775
    directory security mask = 0755
    force directory security mode = 0755

    [development]
    path = /webdev/development
    writeable = yes
    create mask = 775
    directory mask = 775
    valid users = +ABCCORP+webdevstaging
    force group = ABCCORP+webdevstaging
    # file permission lockdown
    create mode = 775
    force create mode = 775
    security mask = 0775
    force security mode = 0775
    # directory permission lockdown
    directory mode = 775
    force directory mode = 775
    directory security mask = 0755
    force directory security mode = 0755

    [testshare]
    path = /webdev/staging
    writeable = yes
    create mask = 664
    directory mask = 775
    valid users = +ABCCORP+webdevstaging
    force group = ABCCORP+webdevstaging
    # file permission lockdown
    create mode = 775
    force create mode = 775
    security mask = 0775
    force security mode = 0775
    # directory permission lockdown
    directory mode = 775
    force directory mode = 775
    directory security mask = 0775
    force directory security mode = 0775


  2. Re: specific share not accessible, others working fine, after point release upgrade

    On Apr 20, 4:07 pm, Paul wrote:
    > I've got a strange situation where sharing a particular directory as
    > follows is not accesible:
    >
    >
    > I think it broke when I updated Samba on Fedora Core 5 from
    > 3.0.23c-1.fc5 to 3.0.24-4.fc5. I've tried any number of things short
    > of rebooting the Samba server.
    >
    > It seems as if there's something cached or corrupted somewhere, but
    > I'm stumped. Does anyone have any suggestions? I have debug level 10
    > logs of what's happening that I can include. My smb.conf is below with
    > a couple things redacted. The 'root' share and the 'development' share
    > both work fine. So does the 'testshare' share, as I said above. I
    > tried all the standard troubleshooting with wbinfo, kinit, and getent
    > and they all seem to be returning the correct results.
    >


    When in doubt, try rebooting the clients. I had enough clients
    exhibiting the same behavior that I didn't think to try rebooting
    them. Finally crossed my mind and that did the trick.


+ Reply to Thread