The Synology DS1513+ 5 Bay server (Image from UK Hardware) |
The Synology small format servers have proved to be pretty awesome devices, allowing for hybrid RAID disk configurations and many enterprise server grade functions by means of downloadable apps.
Recently we had a Synology DS1513+ server that had developed a glitch.
It was used as a file server in a predominantly Windows based environment, and had the Windows File Sharing service enabled. As the network was running as a workgroup, the Master Browser option was enabled on the Synology server. This should have caused the always on server to be the device that held onto and updated the list of other network devices and their names and addresses (Used when you open the Network Browser on a computers and see all the available devices). This worked fine, but in enabling the Master Browser, the shared folders on the Synology became inaccessible.
There are not many options to easily diagnose the cause of the issue without digging a bit further into the Synology server system.
First of all, we checked the workstations and server were all synchronising clocks correctly, in domain settings a wrongly configured clock on a file server can cause user authentication to fail. We setup the network firewall as the time-server and pointed all the devices at that.
Then we enabled the file transfer logs and SMB logs on the Synology server. This is a good fault-finding activity but the logs quickly grow in size so remember to either configure them to stay below a certain size, or disable the logging of unnecessary data after you’ve solved the problem.
The Synology uses a customised version of Linux to run the operating system. You can enable SSH to login via a secure shell rather than through the web front end. root access is also accessible via the SSH so you should have very strict controls about who can access it, and disable it when it’s not needed.Windows shares are handled by the samba daemon, with the config held in the smb.conf file, and extended logs held in the logs/samba folder.
We inspecting the log for SMB and noticed the samba daemon was attempting to authenticate users, but not finding their accounts. So we turned to the smb.conf file to check the configuration. While it looked like it had all the basic bits needed for the samba daemon to run, it was missing some vital config lines. In this case the samba daemon authentication was not tied to the Synology account manager, meaning the daemon did not have access to the user accounts and could not verify them.
We assume during the smb.conf update when the master browser was enabled, something went wrong and the file was not saved properly.
So here’s what the [Global] section of the smb.conf should look like:
[global] workgroup = WorkgroupName server string = WorkgroupServerString encrypt passwords = yes local master = no netbios name = ServerNETBIOSName syno sync dctime = no passdb backend = smbpasswd max protocol = SMB3
updating the smb.conf and restarting the SMB service in the web front end, we tried to access a shared folder again, and had success, all were able to see the server and authenticate against it. Then we checked the Master Browser tag for the workgroup, and sure enough the Synology had it. All back working as it should be.
If you need help managing your workgroups, network, servers or have any network security issues, give us a call today.
#WeCanHelp #Synology #ServerSecurity #Samba #Linux
tinsleyNET IT Services Consultant
IT Support for small to medium or large sized businesses, home office workers and home users
across the UK based, based in the West Midlands and Shropshire.
#WeCanHelp
Leave a Comment