[Samba] smbcontrol smbd reload-config or service smbd reload doesn't reload include files

[Sabuj Pattanayek]

Hi,

I noticed that smbcontrol smbd reload-config or service smbd reload doesn't
reload include files. Is there anyway to get a reload to reload files that
have been included from the main smb.conf ? Otherwise it only looks like
restart works, but that causes connections to reset, even in a
ctdb/clustered environment . The only other option it looks like is to just
put everything into the smb.conf file ?

Thanks,
Sabuj

[Marc Muehlfeld]

Hello Sabuj

Post by Sabuj Pattanayek
I noticed that smbcontrol smbd reload-config or service smbd reload doesn't
reload include files. Is there anyway to get a reload to reload files that
have been included from the main smb.conf ? Otherwise it only looks like
restart works, but that causes connections to reset, even in a
ctdb/clustered environment . The only other option it looks like is to just
put everything into the smb.conf file ?

I use include files for printer and shares in production (3.6.23 and
4.1.6) and always do a "smbcontrol all reload-config", what works.

I quickly did a test here on my testsystem (4.1.5) and renamed a
printer, that is in a separate file which is included in smb.conf. Works.


Which version do you use?


Increase the loglevel to at least 4, then do a
# smbcontrol all reload-config
and search your logs for "include". You should see the included files:

# fgrep include /var/log/samba/*
10.99.0.70.log: doing parameter include = /etc/samba/shares.conf
10.99.0.70.log: doing parameter include = /etc/samba/printers.conf
nmbd.log: doing parameter include = /etc/samba/shares.conf
smbd.log: doing parameter include = /etc/samba/shares.conf
smbd.log: doing parameter include = /etc/samba/printers.conf
winbindd.log: doing parameter include = /etc/samba/shares.conf



Regards,
Marc

[Sabuj Pattanayek]

I'm using 4.1.5, but the reload seems to be very inconsistent. Initially it
looks like the problem was that I had defunct security mask parameters in
include files above the one I was changing which was somehow throwing an
"admin users = " parameter in an include file farther down in the main
smb.conf file. In the log file it said it was reading the section I was
modifying in the include file, but if I updated the "admin users = "
parameter for that share it wouldn't take unless I restarted smbd . After I
got rid of the defunct security mask parameters the reload on the updated
admin users = parameter seems to sort of work. What I mean is that if I add
a group to the admin users parameter and then do a reload (or a few reloads
for good measure) I can then connect because of the add group in admin
users. However, if I comment the parameter out and reload several times I
can still connect to the share even after multiple disconnects and
reconnects. The only thing that seems to "remove" the authentication
information is a full restart of smb, then I can longer connect to the
share as was behavior I was looking for.

Post by Marc Muehlfeld
Hello Sabuj
I noticed that smbcontrol smbd reload-config or service smbd reload

Post by Sabuj Pattanayek
doesn't
reload include files. Is there anyway to get a reload to reload files that
have been included from the main smb.conf ? Otherwise it only looks like
restart works, but that causes connections to reset, even in a
ctdb/clustered environment . The only other option it looks like is to just
put everything into the smb.conf file ?

I use include files for printer and shares in production (3.6.23 and
4.1.6) and always do a "smbcontrol all reload-config", what works.
I quickly did a test here on my testsystem (4.1.5) and renamed a printer,
that is in a separate file which is included in smb.conf. Works.
Which version do you use?
Increase the loglevel to at least 4, then do a
# smbcontrol all reload-config
# fgrep include /var/log/samba/*
10.99.0.70.log: doing parameter include = /etc/samba/shares.conf
10.99.0.70.log: doing parameter include = /etc/samba/printers.conf
nmbd.log: doing parameter include = /etc/samba/shares.conf
smbd.log: doing parameter include = /etc/samba/shares.conf
smbd.log: doing parameter include = /etc/samba/printers.conf
winbindd.log: doing parameter include = /etc/samba/shares.conf
Regards,
Marc

[Sabuj Pattanayek]

This is how how my layout looks like :

smb.conf :

[main]

include /path/to/template_shares.conf
include /path/to/some_other_shares.conf
include /path/to/testing_shares.conf

the [testing] share in testing_shares.conf uses a template from
template_shares.conf with

[testing]
copy = template_share
path = /some/other/path
admin users = @someADGroup

..so here after adding a group to admin users and reloading it works, but
then when I comment out admin users and reload it doesn't take effect and
that group still has access to the share. At this point I have to restart.

Post by Sabuj Pattanayek
I'm using 4.1.5, but the reload seems to be very inconsistent. Initially
it looks like the problem was that I had defunct security mask parameters
in include files above the one I was changing which was somehow throwing an
"admin users = " parameter in an include file farther down in the main
smb.conf file. In the log file it said it was reading the section I was
modifying in the include file, but if I updated the "admin users = "
parameter for that share it wouldn't take unless I restarted smbd . After I
got rid of the defunct security mask parameters the reload on the updated
admin users = parameter seems to sort of work. What I mean is that if I add
a group to the admin users parameter and then do a reload (or a few reloads
for good measure) I can then connect because of the add group in admin
users. However, if I comment the parameter out and reload several times I
can still connect to the share even after multiple disconnects and
reconnects. The only thing that seems to "remove" the authentication
information is a full restart of smb, then I can longer connect to the
share as was behavior I was looking for.

Post by Marc Muehlfeld
Hello Sabuj
I noticed that smbcontrol smbd reload-config or service smbd reload

Post by Sabuj Pattanayek
doesn't
reload include files. Is there anyway to get a reload to reload files that
have been included from the main smb.conf ? Otherwise it only looks like
restart works, but that causes connections to reset, even in a
ctdb/clustered environment . The only other option it looks like is to just
put everything into the smb.conf file ?

I use include files for printer and shares in production (3.6.23 and
4.1.6) and always do a "smbcontrol all reload-config", what works.
I quickly did a test here on my testsystem (4.1.5) and renamed a printer,
that is in a separate file which is included in smb.conf. Works.
Which version do you use?
Increase the loglevel to at least 4, then do a
# smbcontrol all reload-config
# fgrep include /var/log/samba/*
10.99.0.70.log: doing parameter include = /etc/samba/shares.conf
10.99.0.70.log: doing parameter include = /etc/samba/printers.conf
nmbd.log: doing parameter include = /etc/samba/shares.conf
smbd.log: doing parameter include = /etc/samba/shares.conf
smbd.log: doing parameter include = /etc/samba/printers.conf
winbindd.log: doing parameter include = /etc/samba/shares.conf
Regards,
Marc

[Sabuj Pattanayek]

s/main/global

Post by Sabuj Pattanayek
[main]
include /path/to/template_shares.conf
include /path/to/some_other_shares.conf
include /path/to/testing_shares.conf
the [testing] share in testing_shares.conf uses a template from
template_shares.conf with
[testing]
copy = template_share
path = /some/other/path
..so here after adding a group to admin users and reloading it works, but
then when I comment out admin users and reload it doesn't take effect and
that group still has access to the share. At this point I have to restart.

Post by Sabuj Pattanayek
I'm using 4.1.5, but the reload seems to be very inconsistent. Initially
it looks like the problem was that I had defunct security mask parameters
in include files above the one I was changing which was somehow throwing an
"admin users = " parameter in an include file farther down in the main
smb.conf file. In the log file it said it was reading the section I was
modifying in the include file, but if I updated the "admin users = "
parameter for that share it wouldn't take unless I restarted smbd . After I
got rid of the defunct security mask parameters the reload on the updated
admin users = parameter seems to sort of work. What I mean is that if I add
a group to the admin users parameter and then do a reload (or a few reloads
for good measure) I can then connect because of the add group in admin
users. However, if I comment the parameter out and reload several times I
can still connect to the share even after multiple disconnects and
reconnects. The only thing that seems to "remove" the authentication
information is a full restart of smb, then I can longer connect to the
share as was behavior I was looking for.

Post by Marc Muehlfeld
Hello Sabuj
I noticed that smbcontrol smbd reload-config or service smbd reload

Post by Sabuj Pattanayek
doesn't
reload include files. Is there anyway to get a reload to reload files that
have been included from the main smb.conf ? Otherwise it only looks like
restart works, but that causes connections to reset, even in a
ctdb/clustered environment . The only other option it looks like is to just
put everything into the smb.conf file ?

I use include files for printer and shares in production (3.6.23 and
4.1.6) and always do a "smbcontrol all reload-config", what works.
I quickly did a test here on my testsystem (4.1.5) and renamed a
printer, that is in a separate file which is included in smb.conf. Works.
Which version do you use?
Increase the loglevel to at least 4, then do a
# smbcontrol all reload-config
# fgrep include /var/log/samba/*
10.99.0.70.log: doing parameter include = /etc/samba/shares.conf
10.99.0.70.log: doing parameter include = /etc/samba/printers.conf
nmbd.log: doing parameter include = /etc/samba/shares.conf
smbd.log: doing parameter include = /etc/samba/shares.conf
smbd.log: doing parameter include = /etc/samba/printers.conf
winbindd.log: doing parameter include = /etc/samba/shares.conf
Regards,
Marc

[Sabuj Pattanayek]

Just tried sernet samba 4.1.6-7, reloading after adding the group doesn't
seem to work at all now. Had to do a restart.

Post by Sabuj Pattanayek
s/main/global

Post by Sabuj Pattanayek
[main]
include /path/to/template_shares.conf
include /path/to/some_other_shares.conf
include /path/to/testing_shares.conf
the [testing] share in testing_shares.conf uses a template from
template_shares.conf with
[testing]
copy = template_share
path = /some/other/path
..so here after adding a group to admin users and reloading it works, but
then when I comment out admin users and reload it doesn't take effect and
that group still has access to the share. At this point I have to restart.

Post by Sabuj Pattanayek
I'm using 4.1.5, but the reload seems to be very inconsistent. Initially
it looks like the problem was that I had defunct security mask parameters
in include files above the one I was changing which was somehow throwing an
"admin users = " parameter in an include file farther down in the main
smb.conf file. In the log file it said it was reading the section I was
modifying in the include file, but if I updated the "admin users = "
parameter for that share it wouldn't take unless I restarted smbd . After I
got rid of the defunct security mask parameters the reload on the updated
admin users = parameter seems to sort of work. What I mean is that if I add
a group to the admin users parameter and then do a reload (or a few reloads
for good measure) I can then connect because of the add group in admin
users. However, if I comment the parameter out and reload several times I
can still connect to the share even after multiple disconnects and
reconnects. The only thing that seems to "remove" the authentication
information is a full restart of smb, then I can longer connect to the
share as was behavior I was looking for.
On Thu, Mar 13, 2014 at 3:03 PM, Marc Muehlfeld <samba at marc-muehlfeld.de

Post by Marc Muehlfeld
Hello Sabuj
I noticed that smbcontrol smbd reload-config or service smbd reload

Post by Sabuj Pattanayek
doesn't
reload include files. Is there anyway to get a reload to reload files that
have been included from the main smb.conf ? Otherwise it only looks like
restart works, but that causes connections to reset, even in a
ctdb/clustered environment . The only other option it looks like is to just
put everything into the smb.conf file ?

I use include files for printer and shares in production (3.6.23 and
4.1.6) and always do a "smbcontrol all reload-config", what works.
I quickly did a test here on my testsystem (4.1.5) and renamed a
printer, that is in a separate file which is included in smb.conf. Works.
Which version do you use?
Increase the loglevel to at least 4, then do a
# smbcontrol all reload-config
# fgrep include /var/log/samba/*
10.99.0.70.log: doing parameter include = /etc/samba/shares.conf
10.99.0.70.log: doing parameter include = /etc/samba/printers.conf
nmbd.log: doing parameter include = /etc/samba/shares.conf
smbd.log: doing parameter include = /etc/samba/shares.conf
smbd.log: doing parameter include = /etc/samba/printers.conf
winbindd.log: doing parameter include = /etc/samba/shares.conf
Regards,
Marc

[Sabuj Pattanayek]

I merged all the shares in on the smb.conf file itself and tried the same
test with commenting admin users in and out, before and after a reload.
Samba still allows access without a restart.

Post by Sabuj Pattanayek
Just tried sernet samba 4.1.6-7, reloading after adding the group doesn't
seem to work at all now. Had to do a restart.

Post by Sabuj Pattanayek
s/main/global

Post by Sabuj Pattanayek
[main]
include /path/to/template_shares.conf
include /path/to/some_other_shares.conf
include /path/to/testing_shares.conf
the [testing] share in testing_shares.conf uses a template from
template_shares.conf with
[testing]
copy = template_share
path = /some/other/path
..so here after adding a group to admin users and reloading it works,
but then when I comment out admin users and reload it doesn't take effect
and that group still has access to the share. At this point I have to
restart.

Post by Sabuj Pattanayek
I'm using 4.1.5, but the reload seems to be very inconsistent.
Initially it looks like the problem was that I had defunct security mask
parameters in include files above the one I was changing which was somehow
throwing an "admin users = " parameter in an include file farther down in
the main smb.conf file. In the log file it said it was reading the section
I was modifying in the include file, but if I updated the "admin users = "
parameter for that share it wouldn't take unless I restarted smbd . After I
got rid of the defunct security mask parameters the reload on the updated
admin users = parameter seems to sort of work. What I mean is that if I add
a group to the admin users parameter and then do a reload (or a few reloads
for good measure) I can then connect because of the add group in admin
users. However, if I comment the parameter out and reload several times I
can still connect to the share even after multiple disconnects and
reconnects. The only thing that seems to "remove" the authentication
information is a full restart of smb, then I can longer connect to the
share as was behavior I was looking for.
On Thu, Mar 13, 2014 at 3:03 PM, Marc Muehlfeld <

Post by Marc Muehlfeld
Hello Sabuj
I noticed that smbcontrol smbd reload-config or service smbd reload

Post by Sabuj Pattanayek
doesn't
reload include files. Is there anyway to get a reload to reload files that
have been included from the main smb.conf ? Otherwise it only looks like
restart works, but that causes connections to reset, even in a
ctdb/clustered environment . The only other option it looks like is to just
put everything into the smb.conf file ?

I use include files for printer and shares in production (3.6.23 and
4.1.6) and always do a "smbcontrol all reload-config", what works.
I quickly did a test here on my testsystem (4.1.5) and renamed a
printer, that is in a separate file which is included in smb.conf. Works.
Which version do you use?
Increase the loglevel to at least 4, then do a
# smbcontrol all reload-config
# fgrep include /var/log/samba/*
10.99.0.70.log: doing parameter include = /etc/samba/shares.conf
10.99.0.70.log: doing parameter include = /etc/samba/printers.conf
nmbd.log: doing parameter include = /etc/samba/shares.conf
smbd.log: doing parameter include = /etc/samba/shares.conf
smbd.log: doing parameter include = /etc/samba/printers.conf
winbindd.log: doing parameter include = /etc/samba/shares.conf
Regards,
Marc

[Sabuj Pattanayek]

Went back to using the include files since there was no difference between
this and the one smb.conf file. There's some strange server caching of auth
info that doesn't expire immediately after a reload. I seem to have to wait

30, 60 seconds ?
I merged all the shares in on the smb.conf file itself and tried the same
test with commenting admin users in and out, before and after a reload.
Samba still allows access without a restart.

Post by Sabuj Pattanayek
Just tried sernet samba 4.1.6-7, reloading after adding the group doesn't
seem to work at all now. Had to do a restart.

Post by Sabuj Pattanayek
s/main/global

Post by Sabuj Pattanayek
[main]
include /path/to/template_shares.conf
include /path/to/some_other_shares.conf
include /path/to/testing_shares.conf
the [testing] share in testing_shares.conf uses a template from
template_shares.conf with
[testing]
copy = template_share
path = /some/other/path
..so here after adding a group to admin users and reloading it works,
but then when I comment out admin users and reload it doesn't take effect
and that group still has access to the share. At this point I have to
restart.

Post by Sabuj Pattanayek
I'm using 4.1.5, but the reload seems to be very inconsistent.
Initially it looks like the problem was that I had defunct security mask
parameters in include files above the one I was changing which was somehow
throwing an "admin users = " parameter in an include file farther down in
the main smb.conf file. In the log file it said it was reading the section
I was modifying in the include file, but if I updated the "admin users = "
parameter for that share it wouldn't take unless I restarted smbd . After I
got rid of the defunct security mask parameters the reload on the updated
admin users = parameter seems to sort of work. What I mean is that if I add
a group to the admin users parameter and then do a reload (or a few reloads
for good measure) I can then connect because of the add group in admin
users. However, if I comment the parameter out and reload several times I
can still connect to the share even after multiple disconnects and
reconnects. The only thing that seems to "remove" the authentication
information is a full restart of smb, then I can longer connect to the
share as was behavior I was looking for.
On Thu, Mar 13, 2014 at 3:03 PM, Marc Muehlfeld <

Post by Marc Muehlfeld
Hello Sabuj
I noticed that smbcontrol smbd reload-config or service smbd reload

Post by Sabuj Pattanayek
doesn't
reload include files. Is there anyway to get a reload to reload files that
have been included from the main smb.conf ? Otherwise it only looks like
restart works, but that causes connections to reset, even in a
ctdb/clustered environment . The only other option it looks like is to just
put everything into the smb.conf file ?

I use include files for printer and shares in production (3.6.23 and
4.1.6) and always do a "smbcontrol all reload-config", what works.
I quickly did a test here on my testsystem (4.1.5) and renamed a
printer, that is in a separate file which is included in smb.conf. Works.
Which version do you use?
Increase the loglevel to at least 4, then do a
# smbcontrol all reload-config
# fgrep include /var/log/samba/*
10.99.0.70.log: doing parameter include = /etc/samba/shares.conf
10.99.0.70.log: doing parameter include = /etc/samba/printers.conf
nmbd.log: doing parameter include = /etc/samba/shares.conf
smbd.log: doing parameter include = /etc/samba/shares.conf
smbd.log: doing parameter include = /etc/samba/printers.conf
winbindd.log: doing parameter include = /etc/samba/shares.conf
Regards,
Marc

[Sabuj Pattanayek]

Well, it may even be a client cache issue. Even after removing admin users
= I can still disconnect and reconnect to the share and descend into
sub-directories which I shouldn't have access to . The only thing that
seems to flush the client's authentication for good is for the user to
logoff and log back in again. So it seems here that the server is probably
doing the reload instantly, but why is the client dictating the
authentication rights when the server should definitely be in control?

Post by Sabuj Pattanayek
Went back to using the include files since there was no difference between
this and the one smb.conf file. There's some strange server caching of auth
info that doesn't expire immediately after a reload. I seem to have to wait

30, 60 seconds ?
I merged all the shares in on the smb.conf file itself and tried the same
test with commenting admin users in and out, before and after a reload.
Samba still allows access without a restart.

Post by Sabuj Pattanayek
Just tried sernet samba 4.1.6-7, reloading after adding the group
doesn't seem to work at all now. Had to do a restart.

Post by Sabuj Pattanayek
s/main/global

Post by Sabuj Pattanayek
[main]
include /path/to/template_shares.conf
include /path/to/some_other_shares.conf
include /path/to/testing_shares.conf
the [testing] share in testing_shares.conf uses a template from
template_shares.conf with
[testing]
copy = template_share
path = /some/other/path
..so here after adding a group to admin users and reloading it works,
but then when I comment out admin users and reload it doesn't take effect
and that group still has access to the share. At this point I have to
restart.

Post by Sabuj Pattanayek
I'm using 4.1.5, but the reload seems to be very inconsistent.
Initially it looks like the problem was that I had defunct security mask
parameters in include files above the one I was changing which was somehow
throwing an "admin users = " parameter in an include file farther down in
the main smb.conf file. In the log file it said it was reading the section
I was modifying in the include file, but if I updated the "admin users = "
parameter for that share it wouldn't take unless I restarted smbd . After I
got rid of the defunct security mask parameters the reload on the updated
admin users = parameter seems to sort of work. What I mean is that if I add
a group to the admin users parameter and then do a reload (or a few reloads
for good measure) I can then connect because of the add group in admin
users. However, if I comment the parameter out and reload several times I
can still connect to the share even after multiple disconnects and
reconnects. The only thing that seems to "remove" the authentication
information is a full restart of smb, then I can longer connect to the
share as was behavior I was looking for.
On Thu, Mar 13, 2014 at 3:03 PM, Marc Muehlfeld <

Post by Marc Muehlfeld
Hello Sabuj
I noticed that smbcontrol smbd reload-config or service smbd reload

Post by Sabuj Pattanayek
doesn't
reload include files. Is there anyway to get a reload to reload files that
have been included from the main smb.conf ? Otherwise it only looks like
restart works, but that causes connections to reset, even in a
ctdb/clustered environment . The only other option it looks like is to just
put everything into the smb.conf file ?

I use include files for printer and shares in production (3.6.23 and
4.1.6) and always do a "smbcontrol all reload-config", what works.
I quickly did a test here on my testsystem (4.1.5) and renamed a
printer, that is in a separate file which is included in smb.conf. Works.
Which version do you use?
Increase the loglevel to at least 4, then do a
# smbcontrol all reload-config
# fgrep include /var/log/samba/*
10.99.0.70.log: doing parameter include = /etc/samba/shares.conf
10.99.0.70.log: doing parameter include = /etc/samba/printers.conf
nmbd.log: doing parameter include = /etc/samba/shares.conf
smbd.log: doing parameter include = /etc/samba/shares.conf
smbd.log: doing parameter include = /etc/samba/printers.conf
winbindd.log: doing parameter include = /etc/samba/shares.conf
Regards,
Marc

[Antun Horvat]

If I am not wrong, smbconfig all reload-config changes will be visible
only on next login.
This is because when you log into the server samba will create a copy of
config object and pass it to the newly forket smbd instance.
At next reload-config, config changes will be visible only to the parent
smbd process and will be given (a copy) to all newly created smbd child
processes.

To force a reload without restarting smbd, use smbstatus to figure out
which clients are logged into the share and close the shares on samba
side by the use of smbcontrol PID close-share SHARE NAME command.

To be clear, I may be wrong with this, but I think this is how it works.
Maybe someone else can confirm this?

Post by Sabuj Pattanayek
Just tried sernet samba 4.1.6-7, reloading after adding the group doesn't
seem to work at all now. Had to do a restart.

Post by Sabuj Pattanayek
s/main/global

Post by Sabuj Pattanayek
[main]
include /path/to/template_shares.conf
include /path/to/some_other_shares.conf
include /path/to/testing_shares.conf
the [testing] share in testing_shares.conf uses a template from
template_shares.conf with
[testing]
copy = template_share
path = /some/other/path
..so here after adding a group to admin users and reloading it works, but
then when I comment out admin users and reload it doesn't take effect and
that group still has access to the share. At this point I have to restart.

Post by Sabuj Pattanayek
I'm using 4.1.5, but the reload seems to be very inconsistent. Initially
it looks like the problem was that I had defunct security mask parameters
in include files above the one I was changing which was somehow throwing an
"admin users = " parameter in an include file farther down in the main
smb.conf file. In the log file it said it was reading the section I was
modifying in the include file, but if I updated the "admin users = "
parameter for that share it wouldn't take unless I restarted smbd . After I
got rid of the defunct security mask parameters the reload on the updated
admin users = parameter seems to sort of work. What I mean is that if I add
a group to the admin users parameter and then do a reload (or a few reloads
for good measure) I can then connect because of the add group in admin
users. However, if I comment the parameter out and reload several times I
can still connect to the share even after multiple disconnects and
reconnects. The only thing that seems to "remove" the authentication
information is a full restart of smb, then I can longer connect to the
share as was behavior I was looking for.
On Thu, Mar 13, 2014 at 3:03 PM, Marc Muehlfeld <samba at marc-muehlfeld.de

Post by Marc Muehlfeld
Hello Sabuj
I noticed that smbcontrol smbd reload-config or service smbd reload

Post by Sabuj Pattanayek
doesn't
reload include files. Is there anyway to get a reload to reload files that
have been included from the main smb.conf ? Otherwise it only looks like
restart works, but that causes connections to reset, even in a
ctdb/clustered environment . The only other option it looks like is to just
put everything into the smb.conf file ?

I use include files for printer and shares in production (3.6.23 and
4.1.6) and always do a "smbcontrol all reload-config", what works.
I quickly did a test here on my testsystem (4.1.5) and renamed a
printer, that is in a separate file which is included in smb.conf. Works.
Which version do you use?
Increase the loglevel to at least 4, then do a
# smbcontrol all reload-config
# fgrep include /var/log/samba/*
10.99.0.70.log: doing parameter include = /etc/samba/shares.conf
10.99.0.70.log: doing parameter include = /etc/samba/printers.conf
nmbd.log: doing parameter include = /etc/samba/shares.conf
smbd.log: doing parameter include = /etc/samba/shares.conf
smbd.log: doing parameter include = /etc/samba/printers.conf
winbindd.log: doing parameter include = /etc/samba/shares.conf
Regards,
Marc

[Sabuj Pattanayek]

Post by Antun Horvat
To force a reload without restarting smbd, use smbstatus to figure out
which clients are logged into the share and close the shares on samba side
by the use of smbcontrol PID close-share SHARE NAME command.

Will try, but how his this different from disconnecting from the share and
reconnecting? Shouldn't the forked smbd close after this happens? So far
the only two surefire ways to make sure the "admin user = " and perhaps
other parameters take effect after a reload are :

1) completely logout and log back in on the client (which is attached to
the same domain)
2) restart samba

[Antun Horvat]

The smbcontrol PID close-share SHARE_NAME will essentially close the
associated users connection and as a result running smbd process will be
terminated. If the client tries to access the share again, windows will
"reopen" a connection and new smbd will be spawned with new
configuration directives.

The thing is that when you open a share in a explorer and than close the
explorer, the connection to the server is not closed. The connection is
still open for certain amount of time, and only after some timeout it is
closed.
You can check this behavior via *netstat -n* or *net use* command.

Post by Antun Horvat
To force a reload without restarting smbd, use smbstatus to figure
out which clients are logged into the share and close the shares
on samba side by the use of smbcontrol PID close-share SHARE NAME
command.
Will try, but how his this different from disconnecting from the share
and reconnecting? Shouldn't the forked smbd close after this happens?
So far the only two surefire ways to make sure the "admin user = " and
1) completely logout and log back in on the client (which is attached
to the same domain)
2) restart samba

[Sabuj Pattanayek]

Post by Antun Horvat
The thing is that when you open a share in a explorer and than close the
explorer, the connection to the server is not closed. The connection is
still open for certain amount of time, and only after some timeout it is
closed.
You can check this behavior via *netstat -n* or *net use* command.

So disconnect in windows really doesn't disconnect, hah, figures. Will try
the smbcontrol option.

[Antun Horvat]

I forgot to mention one other thing about smbcontrol.
smbcontrol binary for me works only on Samba servers configured as
domain member, not as AD DCs.

Post by Antun Horvat
To force a reload without restarting smbd, use smbstatus to figure
out which clients are logged into the share and close the shares
on samba side by the use of smbcontrol PID close-share SHARE NAME
command.
Will try, but how his this different from disconnecting from the share
and reconnecting? Shouldn't the forked smbd close after this happens?
So far the only two surefire ways to make sure the "admin user = " and
1) completely logout and log back in on the client (which is attached
to the same domain)
2) restart samba

[Marc Muehlfeld]

Post by Antun Horvat
If I am not wrong, smbconfig all reload-config changes will be visible
only on next login.
This is because when you log into the server samba will create a copy of
config object and pass it to the newly forket smbd instance.
At next reload-config, config changes will be visible only to the parent
smbd process and will be given (a copy) to all newly created smbd child
processes.

The 'smbconfig all reload-config' is for all smbd/nmbd/winbind/(don't
know if for samba too) processes - including child processes.

E. g. if you add a printer or a share, the changes are are directly
usable by clients.

But some parameters are used, when the machine connects. E. g. if you
have 'max protocol = NT1' and then increase it to SMB3, the reload
wouln't have an effect, because the client negotiates this when he's
connecting.

So it depents on the parameters if the reload bring the changes directly
to your clients or on the next login or reboot (like 'msdfs root').


Regards,
Marc