Start a Conversation

Unsolved

Closed

7 Posts

1098

March 15th, 2023 08:00

Mounting the BoostFS file system

We are using a Data Domain 6400 Bought last year and still trying to get it working. No one in Dell support has been able to help us accomplish the task of configuring it with DDBoost to our Windows server. 

Current issue,

Having issues with Mounting the BoostFS file system on a windows server.  

\\datadomain\Storage_SU: Configuration initialization failed

Any and all help is appreciated!

March 20th, 2023 01:00

so what did you do already, what procedure did you follow? what version of the OS? What version of boostFS? What DDOS version is the dd4500 running? How is it intended to be used?

If you want anyone to respond in a meaningful way, you at least have to supply the bare minimum of what you have and what you did and what you wanna do?

7 Posts

March 20th, 2023 07:00

Current environment:

Data Domain 6400
Data Domain OS 7.7.4.0-1017976

Windows Server 2019 Datacenter
Version: 10.0.17763 Build 17763
BoostFS 7.7.4.0 Installed

From the Administration : BoostFS CMD Prompt
Command trying to run is: boostfs mount -d dd6400 -s BoostFS_SU -o security=krb5 -o krb-auto-renew=true -u boostuser S:

Invalid option: \\dd6400.sfld.ad\BoostFS_SU
\\dd6400\BoostFS_SU: Configuration initialization failed

I'm using the instructions found at https://www.delltechnologies.com/asset/en-us/products/data-protection/technical-support/h18833-dell-emc-data-domain-boost-file-system-deployment-and-configuration-wp.pdf

 

 

March 20th, 2023 14:00

Still that only seems to be a part of the equation? As the document referenced doesn't clearly state what to do when Kerberos authentication is required? You used the link from the referenced document that points to https://dl.dell.com/content/docu104038_dd-boostfs-for-windows-7-6-configuration-guide.pdf?language=en_us to know exactly what you are supposed to be doing for a Kerberos implementation instead of using the default RSA lockbox option? Might wanna get a manual for 7.7 also, just in case there might be something different or corrected or even changed (see below example of what seems to be in error)?

So stating for example first to arrange "Acquire the storage-unit user ticket" using

# boostfs kerberos set -u <storage-unit-username>

and

(Optional) To verify the creation of the storage-unit user ticket, use the -u option and specify the storage-unit username:
# boostfs kerberos query -u <storage-unit-username>

Where those steps also done? And were they successful?

And after that you'd mount boostfs but still then you would not be able to access it until you would run the command to "Acquire the primary user ticket"? So:

# boostfs kerberos set -m

and:

(Optional) To verify the creation of a primary Kerberos user ticket, use the -m option without specifying a username:
# boostfs kerberos query

Wrg to updated and corrected docs, I also mean for example that it seems - to me - that the step to be run in between "Acquire the storage-unit user ticket" and "Acquire the storage-unit user ticket" to actually mount boostfs, seems to be incorrect, whereas you seem to use the correct option -u ?

Steps
Mount BoostFS and specify Kerberos authentication:
boostfs mount -d -s -o security=krb5 -o username= mount-point>

A bit further down in the "Dell EMC DD BoostFS for Windows Configuration Guide Version 7.6" it states :

boostfs mount -d -s -o security=kerb5 -u
unit-username> <mount-point>

So where all steps performed and also the prereqs fulfilled?

Kerberos authentication uses tickets to authenticate instead of a username and password.

Prerequisites
Verify that each of the following requirements are met:
● The PowerProtect or Data Domain system and the client resolve DNS for each other.
● The client is joined to the same Active Directory domain as the PowerProtect or Data Domain system.
● The PowerProtect or Data Domain system, client, and Active Directory server system clocks must be within five minutes ofeach other. Using an NTP server is a reliable way to keep the clocks synchronized.
● There must be a user in the Kerberos realm with the same name as the storage-unit user local to the PowerProtect or DataDomain system. You must use the Kerberos realm credentials to acquire the storage-unit user ticket, not the credentials local
to the PowerProtect or Data Domain system.

7 Posts

March 25th, 2023 09:00

For the Prerequisites

I have verified all of them except the following.  I'm not sure how to verify this. 

● There must be a user in the Kerberos realm with the same name as the storage-unit user local to the PowerProtect or DataDomain system. You must use the Kerberos realm credentials to acquire the storage-unit user ticket, not the credentials local
to the PowerProtect or Data Domain system.

When I run the following command the results are as follows. 

C:\Program Files\BoostFS>boostfs kerberos query

Primary user wgramlich@ourdomain.COM:
Client Principal: boostuser@ourdomain.AD
Valid Starting: Thu Mar 23 09:53:38 2023
Expires: Thu Mar 23 19:53:38 2023
Renew Until: Fri Mar 24 09:53:38 2023
Service Principal: krbtgt/ourdomain.AD@ourdomain.AD

---------------------------------------------------------------------------------------------------------------------

So stating for example first to arrange "Acquire the storage-unit user ticket" using
# boostfs kerberos set -u 

I ran the following command with the following error message:

C:\Program Files\BoostFS>boostfs kerberos set -u BoostFS_SU
Enter password for storage-unit user BoostFS_SU:

Failed getting initial credentials. -1765328378

I know that I have entered the correct password. 

March 27th, 2023 00:00

Instead of teh actual ddboost user assigned to the Storage Unit (SU) you seem to specify the name of the SU?

should be the ddboost user, which you seem to have specified as being called "boostuser"? Does that user exist in Kerberos even? As that seems to be required.

Is Kerberos what you are really after instead of using the default RSA lockbox option? As then you should also know from Kerberos end, what would be required to be able to authenticate against Kerberos, which would require a user, the same user to be exact also being used on the DD. So not unless that user also exists in Kerberos, you wont be able to do anything with authentication against Kerberos, as what would there be to authenticate against?

7 Posts

March 29th, 2023 12:00

I was able to get some help from Dell Support yesterday.  I had entries in the boostfs.conf file that was also in the mount command.  The Tech informed me that they are not needed in the conf file and remove them.  Entries removed were: UNC Mount Point, \\ddr-name\su-name,  Drive Letter.  Was able to mount after this. 

Also, we turned on debugging "boostfs.exe mount -d dd6400.domain.ad -s BoostFS_SU -o security=krb5 -o storage-unit-username=boostuser -o allow-others=true -o log-level=debug T:"  with the mount command to troubleshoot a different issue.  Got it mounted 1 time and then rebooted having issues mounting again.  Issues with the Kerberos as it creates folders C:\BoostFS\Kerberos but then can't find them with similar names.  Seems like a known issue from the Tech frustration. 

No Events found!

Top