Our device still not working. I can't keep trying all this troubleshooting during the day since my users need the system - localUsers it is for the moment.
Normally you should see the list of your account (it works for me). But i could not use it for the partage... It does not give me some account in this list... But perhaps it works for you?
In fact it should be related to cache that is locked somewhere, but i don t know. Removing the table just permet to get the list with no cache, but i could not use it on the partage page. (writting name, will not propose account or group... )
And if i do not do that, the error is still the same:
[16-06-01 15:04:44] 2355 rndb_account.c:963 info: 394 domain user found [16-06-01 15:04:44] 2355 rndb_account.c:989 info: 100/394 users imported so far [16-06-01 15:04:44] 2355 rndb_account.c:989 info: 200/394 users imported so far [16-06-01 15:04:44] 2355 rndb_account.c:989 info: 300/394 users imported so far [16-06-01 15:04:44] 2355 rndb_account.c:1204 info: 394/394 users imported in 516ms. [16-06-01 15:04:44] 2355 rndb_account.c:2262 error: Error. Fail to insert $home_folder/$user/$group/$group_has_user [16-06-01 15:04:44] 2355 rndb_account.c:2405 error: rndb_ads_account_import() ==> 3 (1246ms) [16-06-01 15:04:44] 2355 rndb_api.c:956 error: rndb_import_nolock() ==> 3 (1247ms)
Hello, in fact, in the night the nas as update the account automatically and... lost all...
Does someone have any information from netgear for this problem???
If i reset the nas, does this solve the problem? And if i reset does i lost the datas or just the settings?
EDIT: i have tested your solution (from my original db.sq3 has i just move it and not delete it on the first time). And i have got the same result. If i do:
# systemctl stop readynasd # sqlite3 /var/readynasd/db.sq3 'delete from "$home_folder";'
# net cache flush # systemctl start readynasd
==> i get the list of account immediatly, but if i reboot, or if i wait, i get the same result, it could not synchronise and there is no more account. It only works one time in fact. After that it does not work.
And if i enable "do not cache ADS", i have got the same result. ==> I get the list, but i could not use it in the partage. When i search an account it return no result. So i could not have something working on this nas for the moment...
I have two devices ReadyNAS 2120. After I accidentally updated one of them to 6.5 I got the same problem Active Directory "Import Error" (another one is still 6.4.2 and works properly).
I called the support and after much vituperation and slander was poured on them a support engineer (Mateusz Janowicz) eventually fixed the problem remotely.
They have not explained the issue and how to fix it.
The only recommendation I can give is to follow the same pattern.
I fixed this issue on my Ultra2-plus (unofficially running OS6). I upgraded from 6.4.2 to 6.5 last week and had the same import error.
On checking some of the posts in this thread it was mentioned about purging the contents on the db.sq3 database. On my system when I ran a select from the $home_folder table I found I had 1 entry which didn't match the $users table.
cd /var/readynasd/
sqlite3
sqlite> .open db.sq3
sqlite> select * from "$home_folder";
I had 4 entries of which one didn't match - the first field is user_id
32768|0|0||1
I confirmed that by using
sqlite> select * from "$user" where id = 32768;
if you have a dodgy entry or 2 then just use sql delete
sqlite> delete from "$home_folder" where user_id = <dodgy_id>;
ctrl-d exits the sqlite3
restart readynasd process using the commands from a previous post.
"sqlite3 /var/readynasd/db.sq3 'delete from "$home_folder";'"
but more specific.
And it does not work for me.
Did you try to reboot your nas, or try a manual synchronisation after? Has i said, it'works "ones" but if you try after or reboot the nas, it never work again until you do again
sqlite3 /var/readynasd/db.sq3 'delete from "$home_folder";' (or your command)
That's the case for me. And i made a select i only have: select * from "$home_folder"; 32768|0|0||0
That do not exist in $user. but after a restart or a time, it go back again.
So it does not solve the "source" of the problem but the result. 😕
I have got the same line 32768 that do not exist in $USER. But has i said, if i delete, it come back again.
If i delete the line, i could made only ONE import of ad, and all seems to look normally. But then, if i reboot the nas, or if i just go into setting and make an manual update ===> same problem. In fact, even if i do nothing, it will automatically try to do it again on some time, and will result in the same.
That's why i ask you if you reboot your nas, it works again?
Checking in my smb.conf I noticed the userid mapping (between Samba AD and Unix) is set to start at 32768 so I presume the 1st user must have been assigned that id. On checking the /home/<DOMAIN> directory the home folder of Administrator was owned by 32768. I presume something has screwed up with the id assignment during the upgrade. Not sure how to reset this assignement yet, that was my next step.
I've got exactly the same issue - my ReadyNAS 316 has been nothing more than an expensive decorative brick since this started.
Please Netgear, if you're able to fix this by an engineer remote accessing, then you must be able to automate the same fix with a firmware patch, or at least provide some instructions so that we can implement it ourselves.
Silence on this is simply not acceptable, we need information asap please.
After that, i have got problem with my save. I am going to reset the nas and start from the begining has i could not make any save and no solution happen. 😕
After the engineers remotely connected to my RN and got it working again, I asked what they did to fix it. Here is the answer that I was given:
"He changed the idmap backend back to what it was before. He also had to clear the $home_folder table in management service database due to some conflicting IDs."
I am now having a similar issue with my other RN2120, but I have no idea how to change the "idmap backend back to what it was before" nor do I know how to clear the $home_folder table. I can SSH into the device and browse the various folders without any problem, but actually applying the fixes is where I can't continue any further.
Yeah idmap is the area I was looking into. Not found anything on it but am now at work so can't check anything until back at home. There must be a way of resetting it. Hopefully someone will comment with some commands 🙂
Think I've managed to fix this on my readyNAS. Granted it was a bit of a belt and braces approach based on google searches I did. Also I installed a vm edition of readynas os 6.5 and confirmed the file I delete is not on the base install after adding to AD domain.
so
1. cd /var/lib/samba
2. mkdir backup
3. cp -p *.tdb backup
4. confirm files in backup : ls -l backup
5. rm winbindd_idmap.tdb
6. reboot
After the reboot I used the GUI to redo my Accounts and they imported fine. I then rebooted and it still worked.
However I think my permissions on /home/<DOMAIN>/users are a little screwed as the idmaps have changed. so it's just a matter of running...
cd /home/<DOMAIN>
chown <user> <user>
cd <user>
find . -exec chown <user> {} \;
perhaps also need to do the same for chgrp too. Fixing file perms is easy peasy compared to the import issue.
Fixing permissions using SSH is not something we would support end users doing and if you encounter problems with that support may be unable to help. You can obviously compare with another NAS (if you have one configured and in a working condition) and if it works for you then good for you.
If you contact support and if required purchase support (if your unit is out of entitlement) then support can probably fix this in a way that the ownership is what it was before the problem (obviously this is not possible if you try doing your SSH changes you mentioned above).
