-1

I am running a ClearCase server on RHEL 6.7. We had a power outage last night (for the life of me I do not know why we don't have damn UPS). At any rate, when the machine was brought back up, we are experiencing some issues with respect to accessing shares on the ClearCase server. When trying to access mapped shares (\ccserver\CLEARCASE), it fails. When trying the hostname (\ccserver), you can see the available shares (the CLEARCASE share, as well as a share associated with the domain user).

I have no idea why there would suddenly be problems here. Nothing changed at all. Smb.conf is listed below:

 [global]
 workgroup = NAVSERV
 server string = Samba Server Version %v
 client signing = yes
 kerberos method = secrets and keytab
 log level = 10
 # logs split per machine
 log file = /var/log/samba/log.%m
 # max 50KB per log file, then rotate
 max log size = 50
 security = ads
 realm = NAVSERV.LOCAL
 # the login script name depends on the machine name
 # the login script name depends on the unix user used
 # disables profiles support by specifing an empty path
 load printers = yes
 cups options = raw
 #obtain list of printers automatically on SystemVz

 [homes]
 comment = Home Directories
 browseable = no
 read only = no

 [printers]
 comment = All Printers
 path = /var/spool/samba/
 browseable = no
 printable = yes
 guest ok = yes
 read only = no

 [CLEARCASE]
 path = /clearcase/
 guest ok = yes
 read only = no

Could this be an issue related to the domain server or something? I am not inclined to believe that since my windows machine can see the hostname and the available shares, it just can't access them.

EDIT:

Contents of log.smbd Contents of log.nmbd

Edit 2: Solution posted below

  • Check the status of smb service on rhel – Ijaz Ahmad Khan Jan 7 '16 at 19:56
  • What errors do you get in the Samba log files? – roaima Jan 7 '16 at 20:02
  • I added two links containing contents of the logfiles – basil Jan 7 '16 at 20:34
  • if this isn't resolved yet, are these messages in your log.nmbd normal? see if they exist in previous (working) days' logs: "find_name_on_subnet: on subnet 172.27.249.54 - name GPS_TAC<1b> NOT FOUND" – Jeff Schaller Jan 8 '16 at 12:01
1

Thanks all. After a lot of searching and delving into logs, I was able to determine that SELinux was preventing access. The solution was simply to run:

setenforce 0
service smb restart
0

There might be some problem with smb services after reboot. Make sure:

  chkconfig smb on
  chkconfig nmb on
  service smb restart
  service nmb restart

Also check the /etc/fstab file. The drive names may have changed after reboot. Use UUIDs instead.

Also check the permissions on the mount point , and proper selinux labels.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.