Beginner question, I'm simulating a disk failure and trying restore my data, but no files are showing

[alyflex]

I just built my first NAS, and I'm currently trying to learn and test it out. My NAS has 2 18TB HDDs that I plan to run in mirrored mode. (I might add more later as I get more familiar with everything and decide on what I actually want/need)

I installed TrueNAS Scale on a separate SSD set up a simple dataset and put a few files on the HDDS.

Today I wanted to simulate a disk failure, and shutdown my NAS. I then physically removed the SATA cable to one of the HDD drives and formatted my SSD drive and reinstalled TrueNAS on the SSD drive (I guess formatting the SSD drive wasn't needed, but I wanted to be sure that I wouldn't have any problem connecting to the HDDs on a new TrueNAS)
Once TrueNAS was reinstalled and booted up I then clicked the Import Pool option and it showed me one available option for my HDD, which I took.

My storage dashboard now shows:

Which makes sense since it is missing one of the two expected mirrored HDDs. It is also showing that the drive has used 2.81 GiB, which are the files I am expecting to still be on the drive. However, when I actually connect to the drive from my normal desktop computer I am unable to see any files in the SMB folder and I don't understand why that is the case.

I am pretty sure it is just something minor and stupid I am missing, but I haven't been able to find any information on this forum or in any guides as to what it could be. So any help would be greatly appreciated.

 

[winnielinnie]

Permissions issue?

Not sharing out the correct path?

Accidentally writing files inside the top-level root dataset itself?

Using the terminal, what are the contents of:

Code:

ls -lh /mnt/DataStore

 

[MrGuvernment]

Ya, first thought for me is permissions. Even if you set up the same user name and password, accounts usually have a unique ID tied to them so this would not match (thinking like Active Directory)

 

[alyflex]

Permissions issue?

Not sharing out the correct path?

Accidentally writing files inside the top-level root dataset itself?

Using the terminal, what are the contents of:

Code:

ls -lh /mnt/DataStore

I can indeed see the files on the command line:

But I still cannot access them through SMB.
I just set up the user tue, and made him the owner of the Share folder under DataStore and applied it recursively, and as evidenced by the above the files do indeed appear to be owned and readable by tue now.

If I look at the details for Share I see:

where I once again see the user tue having read access. One thing that does look strange is that the owner here is root.

If I look at the credentials screen I also do not see anything strange:

 

[alyflex]

Ya, first thought for me is permissions. Even if you set up the same user name and password, accounts usually have a unique ID tied to them so this would not match (thinking like Active Directory)

I see directory services under credentials, and can see that active directory and LDAP are disabled. I haven't touched these at any point and do not have any idea what they do. Is this something I need to do anything about to restore visibility of my files?
From a quick google search on active directory I'm not sure exactly what this does, but it seems like an alternative to setting up the ACL permissions? (Which I will admit I do not quite understand either at this point)

 

[Jailer]

Did you upload a saved config after you re installed TrueNAS? If you didn't did you set up the SMB share again and turn on the SMB service?

 

[alyflex]

Did you upload a saved config after you re installed TrueNAS? If you didn't did you set up the SMB share again and turn on the SMB service?

I did not upload a saved config. I turned on the SMB service and the NFS service again.

But I failed to set them up correctly, which was the needed fix. Now I can see my files again.
Thank you!

 

[MrGuvernment]

No, the AD/LDAP was just me doing a reference to accounts.
While you may of created the accounts with the same names, their are other ID's tied to users that are often referenced "in the background"
so while to you the names and passwords are the same... to the system, they are not

if you go under Accounts/user you can see the UID of each account

Glad it is all working again for you!

Now save a backup config, just in case!