Description of problem: ============================================== With the latest version of glusterfs the gluster volume is not accessible from Windows client.Tried in the AD setup as well as non AD setup, the windows client is not able to access the gluster volume. *********** Tried accessing the xfs-share via samba and it is working fine, the problem is with the access of gluster volume via windows. With Linuc client the mount is successfull and the volume is accessible. Version-Release number of selected component (if applicable): glusterfs-3.5qa2-0.340.gitc193996.el6rhs.x86_64 samba-glusterfs-3.6.9-168.1.el6rhs.x86_64 How reproducible: Always Steps to Reproduce: 1. Create a gluster volume 2. start the volume which creates the samba share 3. Try to access the share via SMB from Windows client. Actual results: ============================================= The Windows client fails to access the gluster volume and gives following error. "gluster vol is not accessible" Not enough storage is available to process this command. Messages from smbd logs: ============================================= 2014/04/21 18:07:06.983516, 3] smbd/msdfs.c:891(get_referred_path) get_referred_path: |gluster-test-vol| in dfs path \10.16.159.197\gluster-test-vol is not a dfs root. [2014/04/21 18:07:07.324500, 4] smbd/sec_ctx.c:314(set_sec_ctx) setting sec ctx (0, 0) - sec_ctx_stack_ndx = 0 [2014/04/21 18:07:07.324677, 3] lib/access.c:338(allow_access) Allowed connection from 10.70.35.48 (10.70.35.48) [2014/04/21 18:07:11.940615, 4] smbd/sec_ctx.c:314(set_sec_ctx) setting sec ctx (11104, 10513) - sec_ctx_stack_ndx = 0 [2014/04/21 18:07:11.940882, 3] smbd/msdfs.c:891(get_referred_path) get_referred_path: |gluster-test-vol| in dfs path \10.16.159.197\gluster-test-vol is not a dfs root. [2014/04/21 18:07:12.279169, 4] smbd/sec_ctx.c:314(set_sec_ctx) setting sec ctx (0, 0) - sec_ctx_stack_ndx = 0 [2014/04/21 18:07:12.279354, 3] lib/access.c:338(allow_access) Allowed connection from 10.70.35.48 (10.70.35.48) [2014/04/21 18:07:12.619438, 4] smbd/sec_ctx.c:314(set_sec_ctx) setting sec ctx (0, 0) - sec_ctx_stack_ndx = 0 [2014/04/21 18:07:12.619644, 3] lib/access.c:338(allow_access) Allowed connection from 10.70.35.48 (10.70.35.48) [2014/04/21 18:07:24.856695, 2] smbd/process.c:2456(deadtime_fn) Closing idle connection [2014/04/21 18:07:24.857019, 3] smbd/server.c:179(msg_exit_server) got a SHUTDOWN message [2014/04/21 18:07:24.857102, 4] smbd/sec_ctx.c:314(set_sec_ctx) setting sec ctx (0, 0) - sec_ctx_stack_ndx = 0 [2014/04/21 18:07:24.857315, 3] smbd/server_exit.c:181(exit_server_common) Expected results: The volume should be accessible from windows client. Additional info:
As identified, if the GlusterFS volume entry in smb.conf is replaced as follows then it works fine. [gluster-new-vol] comment = For samba share of volume new-vol path = / #!!!! no %P read only = No guest ok = Yes vfs objects = glusterfs glusterfs:loglevel = 7 glusterfs:logfile = /var/log/samba/glusterfs-new-vol.%M.log glusterfs:volume = new-vol But without %P exporting of sub-directories via CTDB is and issue, hence we can modify ctdb.conf file to disable directory check as follows: CTDB_SAMBA_SKIP_SHARE_CHECK = no Will be submitting a patch that removes %P from smb.conf and adds "CTDB_SAMBA_SKIP_SHARE_CHECK=no" to ctdb.conf.
For the first change mentioned above we need to fix BZ 1056012 to make path as / For second one : CTDB_SAMBA_SKIP_SHARE_CHECK = yes Need official CTDB build to verify.With CTDB 2.5 scratch build the issue is tested.
Patch posted to revert the %P patch at http://review.gluster.org/7598.
With the following glusterfs version : glusterfs-server-3.6.0-1.0.el6rhs.x86_64 samba-glusterfs-3.6.9-168.1.el6rhs.x86_64 ctdb2.5-2.5.3-2.el6rhs.x86_64 The windows client is able to access the gluster volume. Also tried to access the volume via CTDB and the volume is accessible. Moving the bug to verified.
Setting flags required to add BZs to RHS 3.0 Errata
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHEA-2014-1278.html