Created attachment 11368 [details] Samba Crash Report sent to Root Mail CentOS Linux release 7.1.1503 (Core) Samba Version 4.1.12 Glusterfs 3.7.3 Windows 2012 R2 Standard On a windows client that is a member of the domain, the directories shared by CentOS server works as long as I don't attempt to view permissions on the folder/files in the directory. I can change, write, delete normally. However, when I right click and view "security" from a windows member of the domain, Samba crashes. If I restarted samba, everything works again. I've played with multiple different parameters under the share, but none seem to work. Occasionally I do actually see the permissions, but most of the time the permissions from the Windows side say I don't have access. Either way, Samba still crashes. smb.conf -- example [global] workgroup = RANDCOSVR password server = WIN-502JSB1021L.randco.local realm = RANDCO.LOCAL security = ads idmap config * : range = 16777216-33554431 template homedir = /gdata/SMB/users/%U template shell = /bin/bash kerberos method = secrets only winbind use default domain = true winbind offline logon = true server string = Samba Server Version %v log file = /var/log/samba/samba.log log level = 3 max log size = 10000 encrypt passwords = yes passdb backend = tdbsam load printers = no cups options = raw printcap name = /dev/null idmap backend = tdb winbind refresh tickets = yes winbind enum groups = no winbind enum users = no winbind nested groups = yes winbind normalize names = no [homes] path =/SMB/users/%U browseable = Yes writable = Yes vfs objects = glusterfs posix locking = No kernel share modes = No glusterfs:volume = GV-DATA glusterfs:volfile_server = storagea.randco.local valid users = %U@randco.local
From the attachment it's going down here: : , { "address": 139958747006193 : , "build_id": "5283881181ec11ec8a66a86ee9668f7dee9e375a" : , "build_id_offset": 70897 : , "function_name": "glfs_chdir" : , "file_name": "/lib64/libgfapi.so.0" : } so this might be a gluster bug rather than a Samba one. Assigning to Michael to investigate. Jeremy.
This has been resolved since a long time.