7

On our Centos 7 server, I added create mask = 770 to my smb.conf in order to force permissions on the files our Windows users store in a directory. Then from the command line, I entered the following:

# systemctl restart smb.service

# systemctl restart nmb.service

...but the files were not saved with the right permissions. They were saved correctly after a reboot. So what happened in the reboot that (maybe) I could have done from the command line?

Here's the section of the smb.conf:

[image-storage]
     comment = archived image location
     path = /our/samba/path/to/image_storage
     valid users = @NameOfOurGroup
     create mask = 770
     browsable = yes
     writable = yes
     guest ok = no
     force user = imagestore

5 Answers 5

18

Restarting just the service seems like an improvement on rebooting. Even better still is to make use of the config reload that comes with many linux services, including Samba. This feature is often accessed with a SIGHUP signal or via a control program.

Use smbcontrol (man page) to reload the config with the lowest downtime and lowest-possible impact on services already using your shares. So, just run this:

smbcontrol smbd reload-config
2
  • 1
    I had added a new share to the smb.conf and tried the command you wrote (prefixed with sudo). Unfortunately, the new share did not appear. I had to restart the service, then it appeared. Commented Nov 9, 2020 at 10:31
  • Without reboot it works but with rm -R /var/cache/samba/* like @Tox said here askubuntu.com/a/872460/972235
    – phili_b
    Commented May 5, 2022 at 14:34
1

You have the name of the service wrong. Try:

# systemctl restart smb.service
# systemctl restart nmb.service
4
  • I've edited the question to reflect this. This also fails in exactly the same way. Restarting samba does not seem to affect the image_storage directory. Commented Jul 23, 2019 at 12:08
  • my system doesn't even know smb.service or nmb.service but still it has a smb.conf file and reachable shares
    – bvdb
    Commented Sep 23, 2021 at 15:21
  • on my system it is actually systemctl restart smbd.service and systemctl restart nmbd.service if you don't know the name of the service try : systemctl | grep mb and you may find it
    – bvdb
    Commented Sep 23, 2021 at 15:23
  • be sure you want to restart the smb service before using this answer, it will kick connected users. Better to use smbcontrol smbd reload-config if you just want to reload new shares or update config. Commented Jan 8, 2022 at 0:52
1

Samba creates a child processes for each connected user. According to the manual the parent process monitors the config file and automatically reloads it if it changes. So your changes are acted on almost instantly without your doing anything, however the changes are not propagated to the current crop of child processes.

Any new user mounting shares will see your changes.

If you wish to see them

  • Dismount all your samba shares from your windows machine. Your child process on the samba server will die when your last share is unmounted. Mounting a drive creates a new child process with the new settings
  • Or kill your samba child process.
1

This answer was by far the best one for me: Be sure you want to restart the smb service before using this answer, it will kick connected users. Better to use smbcontrol smbd reload-config if you just want to reload new shares or update config. – PrestonDocks Jan 8, 2022 at 0:52

2
  • I used the command smbcontrol smbd reload-config after I added a new share to a server, and I didn't want to have to restart the server, which would have disconnected many users who were using other shares, interrupting their work badly!
    – Matt I.
    Commented May 12, 2023 at 0:32
  • As it’s currently written, your answer is unclear. Please edit to add additional details that will help others understand how this addresses the question asked. You can find more information on how to write good answers in the help center.
    – Community Bot
    Commented May 17, 2023 at 10:47
0

This line

# chcon -Rt samba_share_t /our/samba/path/to/image_storage

fixed the issue without a reboot. As it was explained to me, this line informs SELinux that the share exists.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .