4

I am running a simple samba server setup where users connect to a share which contains folders for specific user groups. The folders are chmod 2770, so only users which are in the correct group can read/write in them.

The problem is that if I change group memberships (i.e. remove user from group / add user to group; changes are in sync between clients and server!) samba does not automatically reload the group memberships for the user, so they can still write to groups that they are no longer a member of etc. I either have to reconnect to the share or to restart samba to apply the changes.

Is there any way to prevent group caching and/or enable group membership reload in samba?

My smb.conf:

[global]
interfaces = ethlan
bind interfaces only = yes
smb ports = 445
workgroup = WORKGROUP
security = user
passdb backend = tdbsam:/var/lib/mysamba/samba.tdb

disable netbios = yes
nt acl support = no
invalid users = root
read only = no
case sensitive = yes
load printers = no
unix extensions = yes

log file = /var/log/samba.log
log level = 1
syslog = 0

use sendfile = yes

[groups]
path = /home/groups
browseable = yes
force create mode = 0770
force directory mode = 2770
hide unreadable = yes

2 Answers 2

3
+50

Instead of restarting the entire Samba service, you should be able to just send it the signal, SIGHUP, to force it to reload it's configuration file.

From the smbd(8) man page:

The configuration file, and any files that it includes, are automatically reloaded every minute, if they change. You can force a reload by sending a SIGHUP to the server. Reloading the configuration file will not affect connections to any service that is already established. Either the user will have to disconnect from the service, or smbd killed and restarted.

The last two sentences are important: current connections are not affected by this.

How you handle the user's connections may vary greatly and depend on the situation.

  • If they are actively using their connection, it may be easier to tell them to reboot their computer for the changes to take affect; that way if they are in the middle of something, they can just do it at their leisure.

  • For individual users, you can kill their connection process (SIGHUP may work, but I'm not sure at the moment); but you may want to have them save and/or close anything they may have open on the share(s) because their connection will be severed. When they access a share again, they will generate a new connection with the new access. You can use smbstatus to find information on the current connections.

  • Restarting Samba. This is a pretty drastic approach, but may be needed in certain situations. This will kill all current connections, forcing them to establish new connections.

  • Wait it out. If the changes aren't needed at a particular time, you can just let the clients reestablish the connections on their own.

0

I think I have the same problem. In my case the group memberships are cached for each samba session process smbstatus -p.

I use this script to kill the processes and "refresh" the membership information:

#/bin/sh

VICTIM="$1"

[ -z "$VICTIM" ] && exit 1

if [ "$VICTIM" = "!" ]; then
    L="$(smbstatus -p 2>/dev/null)"
else
    L="$(smbstatus -p -u "${VICTIM}" 2>/dev/null)"
fi

echo "$L" | while read PID USER GROUP CLIENT IP; do
    getent passwd "$USER" >/dev/null || continue

    kill "$PID" 2>/dev/null
    echo -n .
done
echo " done!"

Windows has no problems with it, because it reconnects to samba automatically. The user will only have a minimal delay before the next call. But: all active file transfers will be cancelled and throw an I/O error to the user.

I automated this with a batchfile and a cronjob. This way the user can kill its own sessions via double-click (and reading about the I/O error problem).

You must log in to answer this question.