Unable to login share folders after migration

[alex_wky]

Good day,

I'm currently in the process of migrating TruenasCore 12.0 (SystemA) to 13.0 (SystemB) due to frequent reboots in SystemA probably due to hardware failure which resulted to errors in one of the dataset in systemA (lets called it dataset1).

Part1, copying the data
Since SystemB is a brand new machine, my migration technique is as follows:
Rysnc SystemA to SystemB non corrupted dataset (lets called it dataset2, dataset3 etc)
I was unable to Rsync dataset1 due to checksum errors, so I copied the files manually via SMB share
I've preserved the naming of the pools and dataset for both SystemA and SystemB

Part2, copying config
After I've verified that the data has been copied over, I then proceed to transfer the config from SystemA to SystemB by
SystemA GUI, System>General> Save Config
SystemB GUI, System>General> Upload Config
The configuration uploaded successfully in SystemB with one minor error to certificate which i don't think is the problem to the share.

Problem
I'm able to access dataset1 but not dataset2,3 etc. windows "you do not have permission to access \\Server Contact your network administrator to request access" I can't access via ubuntu too with the same error.
when in dataset1, in windows right clicking a folder to show advance security and shared user, I was unable to see all the users and user group that was migrated from the config file, all I got was the windows default user/groups

temp solution
I've re-upload the original config for SystemB, and manually add users and groups, I was able to see the users and groups in windows advance security share.
This is not ideal as there are many other config that i'll need to manually do such as certificates, replication task etc.

i'd like to know where i might have gone wrong with the config migration.

thanks

 

[artlessknave]

1. forum rules, specifically hardware for your systems ( see you have the TrueNAS versions at least).
2. I question why you used rsync instead of replication but w/e. might not have handled the corrupted either.
3. you created new datasets, right? did you give yourself permissions to the datasets? cuz they all default to root. I would specular that the way you copied them via smb just gave you permissions.
4. you will not be able to see ACL permissions in windows if you havent enabled ACL permissions on the dataset
5. if you have users with differnt UIDs you will essentially be using different users and the permissions might not match.

 

[alex_wky]

1. forum rules, specifically hardware for your systems ( see you have the TrueNAS versions at least).
2. I question why you used rsync instead of replication but w/e. might not have handled the corrupted either.
3. you created new datasets, right? did you give yourself permissions to the datasets? cuz they all default to root. I would specular that the way you copied them via smb just gave you permissions.
4. you will not be able to see ACL permissions in windows if you havent enabled ACL permissions on the dataset
5. if you have users with differnt UIDs you will essentially be using different users and the permissions might not match.

hi, thanks for taking time to reply, the specs as follows

SyatemA (TruenasCore 12.0)
Intel(R) Xeon(R) CPU E3-1245 V2 @ 3.40GHz
Asus B75M-PLUS motherboard
Kingston hyperx DDR3 1600 8GB X 4
Kingfast 32GB SSD (Boot)
Tanscend 2TB SSD X 5 (raidz2)

SystemB (TruenasCore 13.0)
Intel(R) Core(TM) i5-10400 CPU @ 2.90GHz
MSI B560M motherboard
Kingston hyperx DDR4 2666 16GB X 2
WD Blue 250GB NVME (Boot)
Tanscend 2TB SSD X 5 (raidz2)

I've tried swapping the boot disk from SystemA to SystemB but it would not boot probably because Truenas was installed under legacy boot instead of UEFI so i'm stuck with uploading config file from SystemA to SystemB

2) That hasn't crossed my mind, i'll try replication to see if works.

3) Yes I've given full control to myself.
there are 56 users in SystemA which was successfully transferred to SystemB. Here's something weird i noticed, the user account that was created natively in SystemB have no problem with SMB. All other imported users could not connect via SMB with the above mentioned credential error.

4) the ACL was transferred along when uploading config from SystemA to SystemB. The path for the share was correct.
I've yet to delete the share and re-create the share. I'll try that later to see if it works.

5) I didn't notice of there's any change in the UID, i'll look into that. thanks.

 

[artlessknave]

there are 56 users in SystemA which was successfully transferred to SystemB. Here's something weird i noticed, the user account that was created natively in SystemB have no problem with SMB. All other imported users could not connect via SMB with the above mentioned credential error.

when you are exporting your config, are you checking the box for password seed? because if you do not, I believe the users on systemb would need to have passwords reconfigured.

 

[alex_wky]

when you are exporting your config, are you checking the box for password seed? because if you do not, I believe the users on systemb would need to have passwords reconfigured.

yes that did the trick, thanks.
now existing users is able to access SytemB like they did in SystemA however it's not out of the woods yet.

4) at the moment all the important dataset is available for use. previously only dataset1 was available, now I can access to dataset2,3 it's the less critical dataset that has problem with shares as this are individual dataset (private storage space for each user).

4A) for example User1 has access to dataset1,2,3,4 (dataset 4 is private dataset only accessible to User1)
User1 was only able to access dataset1,2 and 3, and I got the same network permission error when trying to access dataset4
I tried deleting the share and re-sharing but still got the same error. I've tried clearing windows credentials logging off windows and re-login again, Problem 4A persist.

5) I've checked the UID. The UID in native SystemA was successfully transferred to SystemB

in windows right clicking a folder to show advance security and shared user, I was unable to see all the users and user group that was migrated from the config file, all I got was the windows default user/groups

I'm still facing this problem though.

Again thanks for your help,

 

[artlessknave]

in windows right clicking a folder to show advance security and shared user, I was unable to see all the users and user group that was migrated from the config file, all I got was the windows default user/groups

sorry, I have never used this so I have no idea. I control all permissions from TrueNAS.

 

[alex_wky]

Hi, I'd like to give a little update on the situation. The problem is now resolved.
the recap on the problem I've encountered

I'm able to access dataset1 but not dataset2,3 etc. windows "you do not have permission to access \\Server Contact your network administrator to request access" I can't access via ubuntu too with the same error.

Root cause: when i migrated config from SystemA to SystemB I did not check the "export password seed" box

Solution: check the "export password seed box"

when in dataset1, in windows right clicking a folder to show advance security and shared user, I was unable to see all the users and user group that was migrated from the config file, all I got was the windows default user/groups

4A) for example User1 has access to dataset1,2,3,4 (dataset 4 is private dataset only accessible to User1)
User1 was only able to access dataset1,2 and 3, and I got the same network permission error when trying to access dataset4
I tried deleting the share and re-sharing but still got the same error. I've tried clearing windows credentials logging off windows and re-login again, Problem 4A persist.

Root cause: windows stored credential problem

Solution: 1) clear credential for the Truenas shared drive (this method did not work for me)
2) create new windows user, mount the shared drive as new user. should be able to view all available users (this works)
3) if solution 1 didn't work force ACL onto dataset at Storage\Pools\Edit ACL check the "Apply permissions recursively"(this works)

again, thanks to artlessknave for pointing me to the right direction

 

[artlessknave]

solved is good. there is a way to mark the thread as solved, but im not sure how to do so.