SMB shares have path-related configuration issues that may impact service stability: Path does not exist.

[scotrod]

Hey All. After upgrading from 22.12.3.1 to 22.12.4 I got the following message after rebooting:
SMB shares have path-related configuration issues that may impact service stability: (MySMBShareName): Path does not exist.

I have not applied any recent changes to my SMB shares. They (the shares) sit on single dataset that is encrypted. SMB starts upon boot, after I go and enter the passphrase for decrypting the dataset. I've had this config for a few months not and I've never gotten such alert.

What logfiles can I provide for additional details? Could this be related to the new SMB version that ships with this update?

Thanks.

 

[scotrod]

Update: After stopping the auto-start of the SMB service, rebooting TrueNAS, decrypting first the encrypted dataset and then starting the SMB service, the alert is no longer present. It makes sence for the path to not be discovered if the parent dataset is encrypted, but for the past few months I've never gotten such warning and I couldn't even google it. Could this be a new "check" feature?

Anyway, I've got another encrypted dataset that is also parent of an SMB share. I intentionally did not decrypt it to see if it will spit out such error. It didn't.

 

[anodos]

The alert runs every hour (which means it will get cleared later on during next run). It's probably firing in your case before the system is fully up and dataset decrypted. I will add a delay until the system is fully ready. It gets triggered if an SMB share is enabled and unlocked, but there is some sort of problem with the path under it (in your case you have an enabled SMB share with path missing).

 

[anodos]

This may also indicate a logic problem in how shares are being flagged as unlocked. Can you PM me a debug please?

 

[scotrod]

This may also indicate a logic problem in how shares are being flagged as unlocked. Can you PM me a debug please?

Just sent it. I'm still wondering why I didn't get a warning for my other SMB share that was also encrypted. If the check bombs up due to the encryption, it should also tell me that something is wrong with my other dataset as well.

 

[anodos]

There's an issue with logic for checking whether path is encrypted if the path isn't a ZFS mountpoint. Jira ticket: NAS-124598. The test for the alert should have skipped these shares (since they're "locked"), but the paths were erroneously flagged as unlocked, which caused alert on having share configured to non-existent path.

TL;DR, alert is working correctly, but something else is broken.

 

[scotrod]

Thank you a lot for the fast response and RCA.

This is probably a tricky question, but are there reasons for worrying about the data's integrity sitting on those SMB shares which checks for encryption were failed?

All is working fine after I rebooted, first decrypted the parent dataset and then started the SMB service. I guess I'll turn off the auto-start of the SMB service until the bug is fixed.

 

[anodos]

Thank you a lot for the fast response and RCA.

This is probably a tricky question, but are there reasons for worrying about the data's integrity sitting on those SMB shares which checks for encryption were failed?

All is working fine after I rebooted, first decrypted the parent dataset and then started the SMB service. I guess I'll turn off the auto-start of the SMB service until the bug is fixed.

I don't think you need to worry too much. We perform additional path-related validation when actually generating the share configuration. If the path doesn't exist, we won't actually add it to the SMB server running configuration (instead you'll get complaints about it in the middlewared.log).

 

[scotrod]

Again thank you for your help.

 

[ArmoDriver]

I just got one too,

"SMB shares have path-related configuration issues that may impact service stability: Storage: SMB shares containing the apps dataset are not permitted"​

When switching back to 22.12.3.1, that alert no longer exists.

 

[anodos]

I just got one too,

"SMB shares have path-related configuration issues that may impact service stability: Storage: SMB shares containing the apps dataset are not permitted"​

When switching back to 22.12.3.1, that alert no longer exists.

That's because the alert doesn't exist in that version. It's getting triggered by a bug in detection code for whether a path is locked (it's getting flagged as unlocked when it's currently locked). It's on a crontab schedule and so if you leave your server up and the path exists, it'll go away on its own.

 

[ArmoDriver]

thank you! i will change the alert settings to bypass this alert.

 

[Sparkey]

thank you! i will change the alert settings to bypass this alert.

I did the same.

 

[anodos]

I did the same.

The path detection should be getting fixed in next cobia release.