USB Application Accounts messed up RT-AC86U

[mogulman]

I have a USB disk that I use for backups. I noticed that the account I was using no longer works for accessing the Samba (SMB) share. I can create another test account and it works fine. This isn't an SMB 1.0/Windows issue. Firmware 3.0.0.4.384.81992 RT-AC86U

The way it was originally setup. I had an admin type account that was tied to my routing admin login. Then I had my personal account that I created. The admin account couldn't be changed (username, etc). The personal account could be renamed, deleted, etc.

Now, the personal account, somehow is locked and the admin account isn't. Anyway to fix this using a console login? I use this account in many places and would rather not create a brand new account. Also, it seems broken that a non-admin account is now locked in some way.

I tried:
-Removing accounts, but I can't remove the top account. I also can't change the password or username.
-Tried removing the USB device completely and disabling sharing, but that didn't help.
-I really don't want to completely reset the router as I don't want to lose all my settings. Not sure if saving config to a file and restoring will just bring back the issue.

 

[OzarkEdge]

I tried:
-Removing accounts, but I can't remove the top account. I also can't change the password or username.

The top account is the default router admin account, so it can't be removed. But you can change it elsewhere.

If you can't remove the second account that you added, then things are not working correctly. Try rebooting the router. Try adding and removing a third account.

Ultimately, reset the router.

When I experimented with using a router USB HDD, I used my Windows user account credentials for my router admin credentials. Then I did not have to add a user to the router. But I don't use a router HDD anymore... too many glitches make it unreliable.

OE

 

[ColinTaylor]

@mogulman Try this:

nvram unset acc_num
nvram unset acc_list
nvram unset acc_webdavproxy
nvram commit
reboot

NOTE: This resets the Samba/FTP user to admin with a password of admin. I don't know how to change this admin password other than by changing the acc_list variable.

NOTE: Some routers have their passwords encrypted now. Use the instructions in post #16 instead of these.

nvram set acc_num="1"
nvram set acc_list="admin>mypassword"
nvram set acc_webdavproxy="admin>1"
nvram commit
reboot

Change both occurrences of admin to your router Login Name and mypassword to your router Login Password. After the reboot you should be able to add back in your additional Samba/FTP users in the GUI.

If that doesn't work you'll probably have to remove some hidden files in the root of your USB drive.

 

[OzarkEdge]

If that doesn't work you'll have to remove some hidden files in the root of your USB drive.

That sounds easier anyway.

OE

 

[mogulman]

I ended up getting inpatient, because I had other things to do. So I made some screenshots and saved my config.

Saving config, reseting to factory and restoring just restored the bad config..

Had to reset to factory and then manually change everything back to the way I neded it. Now it's working. If it happens again.. I'll trying Colin's way.

 

[cgalex]

I'm also having this problem on my RT-AC88U. It seems to have started around the time of the upgrade to Asuswrt-Merlin 384.18_0 from 387.17_0, though I don't know if that was the cause... I did not access the share for a few days so I can't correlate it to the upgrade. Posting to this "official" forum since it exactly matches @mogulman's description.

My observations:

• As @mogulman reported, in the account list on the "Network Place (Samba) Share / Cloud Disk" tab, the created user name "ABC" is now first and cannot be changed and "admin" is second. In /etc/samba/smbpasswd the order is "nobody", "ABC", "admin".
• Syslog has several of these messages:
  smbd[24667]: build_sam_account: smbpasswd database is corrupt! username ABC with uid 570576 is not in unix passwd database!
• In (slash)etc(slash)passwd, "ABC" is not listed, but "admin" is listed twice, one with user ID 0 (first line) and one with user ID 501 (last line, which is also the sole line in (slash)etc(slash)passwd.custom).
• If I edit (slash)etc(slash)passwd to change the second "admin" to "ABC", the problem is temporarily fixed.
• When the router reboots, the problem returns. The passwd files are recreated with the faulty entries, and I don't know enough about the system to know what creates those files. (I am a fairly experienced Linux user/maintainer, but not at all familiar with the specifics of Asuswrt-Merlin except as a user of the UI.)

Any ideas to help figure out what's causing this? I am happy to try things, run tests, etc. Should I try the nvram commands suggested by @ColinTaylor? What do they do?

Thanks,

Chuck

 

[ColinTaylor]

Any ideas to help figure out what's causing this? I am happy to try things, run tests, etc. Should I try the nvram commands suggested by @ColinTaylor? What do they do?

FYI I've updated my post #3 with some better instructions. The nvram variables contain the user account information used by Samba, FTP and AiCloud. Sometimes these can get out of sync with the other account settings. To see what they're currently set to:

nvram get acc_num
nvram get acc_list
nvram get acc_webdavproxy

 

[cgalex]

FYI I've updated my post #3 with some better instructions. The nvram variables contain the user account information used by Samba, FTP and AiCloud. Sometimes these can get out of sync with the other account settings. To see what they're currently set to:

That seems to have done the trick. Many thanks!

 

[ylsf]

FYI I've updated my post #3 with some better instructions.

Thanks, I also updated to the latest firmware and had an issue with one of my accounts/computers accessing the USB drive after doing it but I used your instructions to fix it.

My "Admin" account was actually my second account before I did anything and the one user account was the first account (i.e. could not edit it). I used your commands to rest everything and add back in the user account which is now the 2nd account. I am not sure if the firmware has a bug but maybe someone more familiar can report this on the firmware thread as it has been at least 3 people that have had the same issues. I just don't know how to describe/post it correctly. I actually had to look into how to connect into my router as I figured I had to SSH in to be able to send the NVRAM commands but it was my first time doing it and your post made it easy! I registered just to thank you!

EDIT - BTW I am on stock 3.0.0.4.384_81992-gdc7a780 firmware and I just updated it on Sunday and had the issue on Monday when tried to connect that second computer.

 

[maxbraketorque]

Upon updating from 384.18 to 384.19, this issue appeared for me as well. The second account that I had previously created for accessing HDs had been transposed to the first account and was no longer configurable. I had to follow Colin's instructions in Post #3 to make the router admin account the first account again and then recreate the second account that is only for accessing HDs.

Thanks Colin.

 

[follower]

Same issue.
solution for me: NVRAM clear. What a nice auto firmware update. Thanks ASUS. You took many hours from me.

 

[MissingTwins]

Same here. AC86U, from 387.17, 384.18 to 384.19,
I saw this problem since 384.18 I think.

The following hash has been scrambled.
I have two nas accounts, I think one of them is system default.
user1 is missing from \etc\passwd completely.

# nvram get acc_num
3

# nvram get acc_list
<user1>xvkpYKdS46lmIXr9S7SR7A==<admin>r6pKvNcKzSyzqUqqEU3n7tFJIhs1AAU2Q9SpNPp9sDg=<nas>mb1FDmQFnzBe2JH9ioY9sYABiriu1HJZO0Qm0r5BvdE=

# nvram get acc_webdavproxy
admin>0<user1>0

# cat \etc\passwd
admin:x:0:0:admin:\root:\bin\sh
nas:x:100:100:nas:\dev\null:\dev\null
nobody:x:65534:65534:nobody:\dev\null:\dev\null
tor:x:65533:65533:tor:\dev\null:\dev\null
admin:x:501:501::\dev\null:\dev\null
nas:x:502:502::\dev\null:\dev\null

 

[ColinTaylor]

Thanks for the info @MissingTwins. So it looks like the acc_list passwords are encrypted now. That makes sense, although I can't see that myself as I use John's firmware.

Can you compare the output of the following command and see if it matches the admin password in acc_list?

nvram get http_passwd

P.S. Can you double check the first characters of the output of nvram get acc_list please? Is it really "<user1>" or is it "user1>"

 

[Homebrew]

ASUS RT-AC86U

Thank you @ColinTaylor - going from 384.18 to 384.19 introduced the problem for me - your instructions worked perfectly & allowed me to just re-add the user.

For any newbie like me - here is a reference to enable ssh on ASUS RT-AC86U: (taken from https://www.htpcguides.com/enable-ssh-asus-routers-without-ssh-keys/)

ASUS Router Simple Local SSH access
Log into the web interface of the Asus Router

Click Administration in the left pane

Click the System Tab

Under SSH Daemon section set Enable SSH to Yes

Set the SSH service port if you don't want to use the standard SSH port (22)

Set Allow SSH password login to Yes

Set Enable SSH Brute Force Protection to Yes

Scroll down and click Apply




After enabling ssh on the router, access the router from a command prompt on a pc with

ssh <your_router_admin_user>@<your.router.ip.address>

enter password, then you'll be at a command prompt where you can enter the instructions (nvram..) from @ColinTaylor

 

[MissingTwins]

Can you compare the output of the following command and see if it matches the admin password in acc_list?

nvram get http_passwd

I can confirm that it matches.
nvram get http_passwd yields r6pKvNcKzSyzqUqqEU3n7tFJIhs1AAU2Q9SpNPp9sDg=

P.S. Can you double check the first characters of the output of nvram get acc_list please? Is it really "<user1>" or is it "user1>"

I have noticed that too, so I can confirm that there is no typo or something.

nvram get acc_list yields <user1>...==<router>...=<nas>...=
nvram get acc_webdavproxy yields admin>0<user1>0 with unpaired <>

 

[ColinTaylor]

Thanks @MissingTwins. I wonder whether the addition of the leading "<" is deliberate or part of the corruption (I suspect the latter).

Perhaps the commands to reset the values should be:

nvram set acc_num="1"
nvram set acc_list="$(nvram get http_username)>$(nvram get http_passwd)"
nvram set acc_webdavproxy="$(nvram get http_username)>1"
nvram commit
reboot

N.B. Your "admin" account name may only contain letters (upper or lower case) and numbers. If it contains any non-alphanumeric characters the fix above will not work.

NB. This no longer works. Security changes mean the nvram command no longer returns password data. Try using this method instead.

 

[MissingTwins]

Thank you very much @ColinTaylor for your advice.

I did this, and my USB Application(Samba) users finally got back into order. Massed-up has been fully restored.

    nvram set acc_num="3"
    nvram set acc_list="admin>r6pKvNcKzSyzqUqqEU3n7tFJIhs1AAU2Q9SpNPp9sDg=<user1>xvkpYKdS46lmIXr9S7SR7A=<nas>mb1FDmQFnzBe2JH9ioY9sYABiriu1HJZO0Qm0r5BvdE="
    nvram set acc_webdavproxy="admin>1<user1>0<nas>0"
    nvram commit
    reboot

 

[ColinTaylor]

That's great news @MissingTwins. I'll update my original post.

 

[Mikii]

Hi. This helped me too regain access to my shared smb directories:

nvram set acc_num="1" nvram set acc_list="admin>mypassword" nvram set acc_webdavproxy="admin>1" nvram commit reboot

Thank you for suggesting it.

 

[Coyotearms]

Thanks @MissingTwins. I wonder whether the addition of the leading "<" is deliberate or part of the corruption (I suspect the latter).

Perhaps the commands to reset the values should be:

nvram set acc_num="1"
nvram set acc_list="$(nvram get http_username)>$(nvram get http_passwd)"
nvram set acc_webdavproxy="$(nvram get http_username)>1"
nvram commit
reboot

THANK YOU SO MUCH! This worked for me and I am also grateful! I was on the phone with ASUS, was sure they understood what I was trying to fix, but they had no clue how to do this.