Open faffige opened 2 years ago
Good catch @faffige! I also have this issue but haven't had the time to dig into it.
@faffige are you working on a PR for this? I also do not have a DSM system to test with, but a simple if statement referencing the DSM version is likely able to allow this for both.
Hi @dougmeek , yes - I am hoping to get on to it tonight/tomorrow
Hi @dougmeek, PR is up - let me know if you have any suggestions
@faffige I'll give it a closer look after work. Initial impressions are that it looks good, but will need to test. Were you able to find a DSM 6 system to test with?
Hi guys, I've been away from github for a few days. I plan on testing this out on DSM 6 shortly.
I managed to figure out licensing for virtual DSM and spun up a DSM 6 instance. Looks like it also sets the owner to DNSServer:DNSServer, I changed it to nobody:nobody and got the same error as DSM7
@faffige So you're saying that DSM 6 and DSM 7 both need DNSServer for their permissions now? I wonder if it wasn't a DSM upgrade that changed that behavior, but rather an upgrade to the DNS server package.
The release notes for DSM (see All versions) reports the following among a long list of change items:
Added the ability to delegate predefined administrator roles to non-administrator user accounts and allow them to manage certain services and system settings, offering more flexible permission management.
Is it possible that the assignment of file ownership results from this change, applying to both major DSM versions?
I dug deeper into the "delegate" feature new to DSM, and no longer suspect strongly that it is related to the observations for the current discussion. The feature is documented by Synology, and also can be seen in the Delegated Administration box in Control Panal (User & Group / User / Delegate). The granularity of roles is quite limited, and none aligns with the name for the user and group, DNSServer
, mentioned earlier.
I am hopeful that others have ideas about how to move this issue forward.
Browsing SynoForum recently, I noticed a significant portion of the activity centered on DSM 7.0. A discussion on that site might attract support from those with any further experience needed to resolve the issues currently open.
I can confirm that with DSM 6 the ownership is DNSServer:DNSServer. I'm preparing to update to DSM 7, and just pulled the latest version of the scripts.
What's odd (to me) is that the ownership on the zone files is still DNSServer:DNSServer, despite the script clearly showing the chown. I'm guessing I'm configured in a way to not trigger that?
In any event, would it be correct for me to change the script as described here? Before or after my update to DSM 7?
@RichSteele: Have you had successful operation on DSM 7?
So far there have been vague hints that it's possible, but no one has referenced a branch that is verified to function properly.
@brainchild0 Yes, no new issues with DSM 7. I decided to not change the permissions and left as nobody:nobody--it's not causing me problems and figure I'd leave it alone until it does.
One thing I'd recommend is to look at https://github.com/gclayburg/synology-diskstation-scripts/issues/27. Not specific to DSM 7--I was getting dupes in DSM 6 as well--but for the record, I'm now running the version of the script that @HHasenack created.
@RichSteele: Thanks for the clarification.
It would be helpful if the project status would be clarified officially with respect to support for DSM 7. This matter has given me confusion for some time, which was not resolved in my previous discussions with others.
I just updated DSM to 7.1-42661 Update 2. (Latest) I'm getting the permission issues on the zone files and it does interfere with add/remove/modifications in the UI. I updated the script on line 200 and changed it to DNSServer:DNSServer. It seems to be working fine now. I'll continue to monitor.
Before
total 8 0 drwxr-xr-x 1 DNSServer DNSServer 70 Jun 6 09:58 . 0 drwxr-xr-x 1 DNSServer DNSServer 58 May 31 09:15 .. 4 -rw-r--r-- 1 nobody nobody 2312 Jun 6 09:58 4.168.192.in-addr.arpa 4 -rw-r--r-- 1 nobody nobody 1800 Jun 6 09:58 home.local
After
total 8 0 drwxr-xr-x 1 DNSServer DNSServer 70 Jun 6 13:10 . 0 drwxr-xr-x 1 DNSServer DNSServer 58 May 31 09:15 .. 4 -rw-r--r-- 1 DNSServer DNSServer 2312 Jun 6 13:10 4.168.192.in-addr.arpa 4 -rw-r--r-- 1 DNSServer DNSServer 1800 Jun 6 13:10 home.local
I will give this a test as well, sorry it has been a while since I have looked at this.
Yep, looks like the perms are still DNSServer:DNSServer, I will give this a go on DSM 6 as well later
In DSM 7, the zone files are owned by DNSServer:DNSServer. Once a sync runs, you can no longer add zone records and get the following errors: create: delete:
diskstation_dns_modify.sh sets the ownership to nobody:nobody which seemingly works fine in DSM 6 https://github.com/gclayburg/synology-diskstation-scripts/blob/d39918122d771ebea6dfb2165c117cffd77cf516/diskstation_dns_modify.sh#L200
modifying line 200 to this: "if ! chown DNSServer:DNSServer $BackupPath/$ForwardMasterFile.bumped $BackupPath/$ReverseMasterFile.bumped ; then" resolved the issue
Unfortunately I do not have a DSM 6 system to test on, so not to sure if raising a PR to merge in the change will be useful