Fixing bad ACL permission on my Synology NAS

Posted on Disqus:

The Issue

Yesterday, I created a new administrator account for my Synology NAS. For easier management, just like usual, I copied my SSH key into the NAS by calling the ssh-copy-id command. Strangely, that didn’t work. And it kept asking me to enter my password every time I log in. This thing had never happened before.

The Diagnosis

Thankfully, I had another backup Synology NAS, which could be the control group for diagnosing. I tried to create a new administrator account on that machine and verified that this problem only happened to my current NAS.

I enabled the SSH verbose mode ssh -v to connect both of my machines and compare their output. I immediately noticed the difference.

Problem NAS

1
2
3
4
5
6
7
8
9
10
11
debug1: Next authentication method: publickey
debug1: Trying private key: /Users/user1/.ssh/id_rsa
debug1: Trying private key: /Users/user1/.ssh/id_ecdsa
debug1: Trying private key: /Users/user1/.ssh/id_ecdsa_sk
debug1: Offering public key: /Users/user1/.ssh/id_ed25519 ED25519
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /Users/user1/.ssh/id_ed25519_sk
debug1: Trying private key: /Users/user1/.ssh/id_xmss
debug1: Trying private key: /Users/user1/.ssh/id_dsa
debug1: Next authentication method: password
[email protected]'s password:

Healthy NAS

1
2
3
4
5
6
7
debug1: Next authentication method: publickey
debug1: Trying private key: /Users/user2/.ssh/id_rsa
debug1: Trying private key: /Users/user2/.ssh/id_ecdsa
debug1: Trying private key: /Users/user2/.ssh/id_ecdsa_sk
debug1: Offering public key: /Users/user2/.ssh/id_ed25519 ED25519
debug1: Server accepts key: /Users/user2/.ssh/id_ed25519 ED25519
Authenticated to 192.168.30.7 ([192.168.30.7]:22) using "publickey".

Looks like the server didn’t accept my SSH key. But that should never happen as I double-checked the authorized_key file on both of my NAS, as well as the file permissions and owner, which were identical.

I would like to check the server log as well. So I started an SSH debug server by calling sudo /bin/sshd -d -p 2222 to try to get the server log. At that time, I finally located the cause of this problem.

Problem NAS

1
2
3
4
debug1: temporarily_use_uid: 1034/100 (e=0/0)
debug1: trying public key file /var/services/homes/user1/.ssh/authorized_keys
debug1: fd 4 clearing O_NONBLOCK
Authentication refused: bad ACL permission for file /volume1/homes/user1/.ssh/authorized_keys

Healthy NAS

1
2
3
4
5
6
debug1: temporarily_use_uid: 1026/100 (e=0/0)
debug1: trying public key file /var/services/homes/user2/.ssh/authorized_keys
debug1: fd 4 clearing O_NONBLOCK
debug1: /var/services/homes/user2/.ssh/authorized_keys:1: matching key found: ED25519
debug1: /var/services/homes/user2/.ssh/authorized_keys:1: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
Accepted key ED25519 found at /var/services/homes/user2/.ssh/authorized_keys:1

So there were some problems with the ACL permissions. I did check my file permissions on the NAS web GUI, it seems normal and flawless.

During the research, I came across this article https://community.synology.com/enu/forum/17/post/111114, realizing that deleting an account could cause this issue. I did remove an unused admin user right before then. So I tried to call ls -el through SSH to check my file permissions. Finally, The reason was clear. There was an unknown user!

1
2
3
4
5
6
7
8
user1@Problem-NAS:~/.ssh$ ls -el
total 4
-rwxrwxrwx+ 1 user1 users 107 Jun 10 21:32 authorized_keys
	 [0] user:user1:allow:rwxpdDaARWcCo:---- (level: 2)
	 [1] group:administrators:allow:rwxpdDaARWc--:---- (level: 3)
	 [2] user:(null):allow:rwxpdDaARWc--:---- (level: 3)
	 [3] everyone::allow:--x----------:---- (level: 3)
	 [4] user:user1:allow:rwxpdDaARWcCo:---- (level: 3)
1
2
3
4
5
6
7
user@Healthy-NAS:~/.ssh$ ls -el
total 4
-rwxrwxrwx+ 1 user2 users 107 Jun  2 16:19 authorized_keys
	 [0] user:user2:allow:rwxpdDaARWcCo:---- (level: 2)
	 [1] group:administrators:allow:rwxpdDaARWc--:---- (level: 3)
	 [2] user:user2:allow:rwxpdDaARWcCo:---- (level: 3)
	 [3] everyone::allow:--x----------:---- (level: 3)

Somehow this unknown user didn’t show up on the GUI. I can only confirm it through SSH. That’s why I didn’t notice it in the first place.

The Solution

Coming from the instinct of a Software Engineer, I believe I can fix this by resetting the permissions list. I don’t want to do that through SSH. Instead, I do that on the Synology Web UI.

  1. Go to the File Station. Right-click the homes shared folder. Select Properties.
  2. Go to the Permission tab and click Create. Arbitrary choose a user and assign permissions. (e.g. I assigned Traverse folders/Execute files permission for user Everyone)
  3. Click Done to save and exit the Permission Editor window and click Save to exit the Properties Window.
  4. Enter the Properties window again. Delete the newly created permission and save.

Updating the permission list on the root shared folder will apply to all the containing files, as permissions are inherited by default.

For me, I have to repeat these steps on most of my shared folders as I also found the unknown user in other locations. I guess I messed up the ACL permissions sometime in the past.

Reference

https://community.synology.com/enu/forum/17/post/111114
https://kb.synology.com/en-uk/DSM/help/FileStation/privilege?version=7
https://community.synology.com/enu/forum/17/post/101650nu/forum/17/post/101650