On Wed, 2018-09-12 at 10:37 -0600, Terry McGuire wrote: > > Can you please attach the output of `testparm -s` so as to look through how > > Samba is setup?
I have a setup where I could browse and work with a GlusterFS volume share made available to Windows via vfs_glusterfs module on CentOS 7.5.1804 with glusterfs-3.10.12-1.el7 and samba-4.7.1-9.el7_5. What am I missing? Are there any specific operation that leads to abnormal behaviours? > From our test server (“nomodule-nofruit” is currently the only well-behaved > share): > > root@mfsuat-01 ~]#testparm -s > Load smb config files from /etc/samba/smb.conf > rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384) > Processing section "[share1]" > Processing section "[share2]" > Processing section "[nomodule]" > Processing section "[nomodule-nofruit]" > Processing section "[module]" > Processing section "[IPC$]" > WARNING: No path in service IPC$ - making it unavailable! > NOTE: Service IPC$ is flagged unavailable. On an unrelated note: I don't think your intention to make [IPC$] unavailable using the 'available' parameter would work at all. > Loaded services file OK. > idmap range not specified for domain '*' > ERROR: Invalid idmap range for domain *! On an unrelated note: Why haven't you specified range for default configuration? I think it is a must to set range for the default configuration. > WARNING: You have some share names that are longer than 12 characters. > These may not be accessible to some older clients. > (Eg. Windows9x, WindowsMe, and smbclient prior to Samba 3.0.) > WARNING: some services use vfs_fruit, others don't. Mounting them in > conjunction on OS X clients > results in undefined behaviour. > > Server role: ROLE_DOMAIN_MEMBER > > # Global parameters > [global] > log file = /var/log/samba/log.%m > map to guest = Bad User > max log size = 50 > realm = XXXX.AD.UALBERTA.CA > security = ADS > workgroup = STS > glusterfs:volume = mfs1 > idmap config * : backend = tdb > access based share enum = Yes > force create mode = 0777 > force directory mode = 0777 > include = /mfsmount/admin/etc/mfs/smb_shares.conf > kernel share modes = No > read only = No > smb encrypt = desired > vfs objects = glusterfs > [share1] > path = /share1 > valid users = @[email protected] > [share2] > path = /share2 > valid users = @[email protected] Oh.. you are sharing sub-directories which is also fine. > [nomodule] > kernel share modes = Yes > path = /mfsmount/share1 > valid users = @[email protected] > vfs objects = fruit streams_xattr Interesting.. Even this FUSE mounted GlusterFS share is not behaving normal? What errors do you see in glusterfs fuse mount log(/var/log/glusterfs/mfsmount-.log) while accessing this share? > > > [nomodule-nofruit] > kernel share modes = Yes > path = /mfsmount/share1 > valid users = @[email protected] > vfs objects = > > > [module] > path = /share1 > valid users = @[email protected] > [IPC$] > available = No > vfs objects = You may remove the whole [IPC$] section. > > > My gluster version initially was 3.10.12. I’ve since updated to gluster > > > 3.12.13, but the > > > symptoms > > > are the same. > > > > > > Does this sound familiar to anyone? > > > > All mentioned symptoms point towards a disconnection. We need to find out > > the origin of this > > disconnection. What do we have in logs under /var/log/samba/? Any errors? > > Actually, yes. Large numbers of: > > [2018/09/12 09:37:17.873711, 0] > ../source3/modules/vfs_glusterfs.c:996(vfs_gluster_stat) > glfs_stat(.) failed: Invalid argument > > There appears to be some sort of connection remaining, as I can continue to > cause these errors in > the server log by attempting I/O with the share. > > This seems like the most promising lead to find the root cause. Hopefully > you (or someone) can > interpret what it means, and what I might do about it (besides not using > vfs_gluster anymore). > > Regards, > Terry _______________________________________________ Gluster-users mailing list [email protected] https://lists.gluster.org/mailman/listinfo/gluster-users
