[shares-admin] NFS/SMB not restarted once shares are added - require manual restart

I confirm that problem. share-admins had to restart services.

as far as i know samba don't need to be restarted when a share is added as the samba server automatically reload itself when its config file is modified (smb.conf)

This also seems to be the case for changing the workgroup name: samba must be restarted for changes to take affect.

I can confirm that samba needs to be restarted after adding a share with shares-admin... tried it just now (otherwise, no change takes effect).

This also means that when removing an SMB share, it remains acessible until samba is manually restarted. This could mislead the user into thinking he / she disabled an unwanted share, when it's not the case.

I haven't tried NFS in that respect.

Samba does reload its own config file occasionally, but it's not instant.

Maybe a samba feature request, it could reload its configuration when the configuration change is modified

As far as I know, Samba reloads it's settings every 60 seconds.

Fixed at least in Gutsy. Samba reloads instantly on config chnage (even when name of workgroup is changed).

Since bug #70590 has been marked as a duplicate of this, I mark this bug as a security problem. In gutsy, you can keep listing a shared folder, and it will never be "unshared". This can cause data to be published without the user knowing.

are you sure it's never unshared?

the upstream bug has a comment

"Samba shouldn't need to be restarted to pick up new shares as it rereads the
samba configuration files every minute or so."

That looks like a samba issue

On Thu, Oct 11, 2007 at 03:45:40PM -0000, Sebastien Bacher wrote:
> "Samba shouldn't need to be restarted to pick up new shares as it rereads the
> samba configuration files every minute or so."
>
> That looks like a samba issue
>

I confirm that samba automatically reload its configuration file if it
has been modified.

However, the new configuration won't be applied to clients already
connected. samba needs to be restarted (and thus break/close all
existing connections).

So if you're connected to a share, unshare it on the server, and keep
the connection open, it will still work. New connections won't succeed
though.

--
Mathias

should sharing a new folder make all the running connections to be restarted? What happens if a copy is running when samba is restarted? it's not clear to me that the current way is not correct

I think that in this case security should matter more than posix semantics, and if a folder is unshared, then all connections reading that folder should be killed. However, this problem should perhaps be discussed on the development mailing list, or with somebody who is committed to ubuntu security.

Another comment: current behavior is to kill *all* the connections when samba is restarted, and this is the only way to securely unshare a folder. Now may be this is a proper samba bug, in the sense that it should be able to reload its configuration but killing only those connections that are no longer allowed. It can be hard to implement but it's the correct solution.