What's new

Samba configuration reload

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

sherion

New Around Here
Is there any way to modify the /tmp/etc/smb.conf file and reload Samba configuration using something like 'killall -s SIGHUP smbd'?
The problem is that the firmware overwrites the contents of smb.conf file according to it's own NVRAM configuration and restarts Samba processes just after execution of all provided /jffs/* scripts, causing all changes made from these sсripts to disappear.
Samba restart events are seen in the system log:

Samba Server: smb daemon is stoped
Samba Server: daemon is started


Samba stop (kill) event occurs even if the drive sharing is disabled in the web interface, that makes no sense of running Samba processes from the start scripts.
The workaround is making symlinks for /usr/sbin/smbd and /usr/sbin/nmbd on usb media with renaming them to something like 'smbd3' and 'nmbd3'. After that you can start symlinked files from jffs scripts without fear that they will be killed (as the name of the processes are different now), but there is a little nuance: ASUS firmare turns on 'Generic Receive Offload' feature while starting Samba server. Yes, at the moment it's the cause of some GRO-related crashes, but maybe this will be fixed by ASUS in the future, and using GRO will result in increased network performance. Thus, it would be better if the Samba start and stop operation would be controlled by firmware.
By the way, if the firmware is compiled with GRO support, is it possible to turn this feature (GRO) on and off by a console command?
 
Is there any way to modify the /tmp/etc/smb.conf file and reload Samba configuration using something like 'killall -s SIGHUP smbd'?
The problem is that the firmware overwrites the contents of smb.conf file according to it's own NVRAM configuration and restarts Samba processes just after execution of all provided /jffs/* scripts, causing all changes made from these sсripts to disappear.

I'm not aware of any way to do this at this time, sorry. I might eventually look at implementing a way to allow people to override some config files such as smb.conf or dnsmasq.conf.

By the way, if the firmware is compiled with GRO support, is it possible to turn this feature (GRO) on and off by a console command?

If the firmware is compiled with GRO support, then it automatically enables it when it starts Samba. They enable it on by writing something to the /proc filesystem when it's enabled, but I don't remember the exact string they write or the actual location, sorry. No idea either if it can be easily turned on and off without rebooting between changes.

I found very little information on GRO when I looked, so I couldn't get any deeper in troubleshooting it. I sent what little information I had to Asus, hoping they would eventually get around to looking into it, as their developers are far more knowledgeable than me in relation to kernel-level stuff.
 

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top