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

Bug #33068 reported by Danson Joseph on 2006-02-27
48
Affects Status Importance Assigned to Milestone
GST
Invalid
Medium
gnome-system-tools (Ubuntu)
Low
Ubuntu Desktop Bugs
samba (Ubuntu)
Wishlist
Unassigned

Bug Description

Hi,

I've tried this on many systems. When a SMB or NFS share is added, the respective service is not automatically restarted to activate the shares. it requires a manual /etc/init.d/nfs-kernel-server restart or samba restart.

Can this be made automatic, especially in terms of end-user ease?

Cheers,
Danson

Patrice Vetsel (vetsel-patrice) wrote :

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

Changed in gnome-system-tools:
status: Unconfirmed → Confirmed
Sebastien Estienne (sebest) wrote :

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)

Lukas Sabota (punkrockguy318) wrote :

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

Nicolas Maquet (nmaquet) wrote :

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.

Adam Conrad (adconrad) wrote :

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

Changed in gst:
status: Unconfirmed → Rejected
Sebastien Bacher (seb128) wrote :

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

Changed in gnome-system-tools:
assignee: nobody → desktop-bugs
importance: Medium → Low
Changed in samba:
importance: Untriaged → Wishlist
fafek2 (fafek2) wrote :

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

Ante Karamatić (ivoks) wrote :

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

Changed in samba:
status: New → Fix Released
Vincenzo Ciancia (vincenzo-ml) wrote :

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.

Sebastien Bacher (seb128) wrote :

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

Sebastien Bacher (seb128) wrote :

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

Vincenzo Ciancia (vincenzo-ml) wrote :

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.

Vincenzo Ciancia (vincenzo-ml) wrote :

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.

Changed in samba:
status: Fix Released → New
Mathias Gug (mathiaz) on 2007-10-22
Changed in samba:
status: New → Triaged
Changed in gst:
importance: Unknown → Medium
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.