According to its man page, mount_smbfs takes its share point argument in the form:
//[domain;][user[:password]@]server[/share]
Note the "user[:password]" part -- the colon and password are in the same brackets, indicating that they're optional but if included, they must be included together. Essentially, if you include the colon, whatever's after it (up to the "@") will be taken the password. But you have nothing after the colon, so you're explicitly specifying a blank password.
Also, the man page says you should never run mount_smbfs directly, but instead use mount -t smbfs.
You need to either include the password explicitly, like this:
mount -t smbfs '//share;user:password@server.domain/share' /Volumes/share
Or leave off both colon and password:
mount -t smbfs '//share;user@server.domain/share' /Volumes/share
...in which case it'll look for a password in ~/Library/Preferences/nsmb.conf, and if it isn't there it'll prompt for one. I had thought that it could look in the keychain, but apparently it doesn't know how to do that. This means that there is no non-interactive, secure way to supply a password to mount_smbfs.
Depending on the context this is running in, you might be able to use the open command instead:
open 'smb://share;user@server.domain/share'
I think this'll need to be running in a user session, and doesn't give you control of the mount point (it'll be auto-created in /Volumes).
Oh, one other thing: the "share;" part of the URL specifies an authentication domain to find the user in. Is that part actually correct? If it is, the open command should work interactively.
From Macrumors (in the Mojave 'All the little things' thread):
Time sync: ntpd has been replaced by timed: not the old school unix one, but a new apple invention.
Have linked the timed Man page for ya:
https://www.unix.com/man-page/mojave/8/timed/
Best Answer
I have this same issue. It seems to only be with Microsoft Office files. PDFs don't seem to have "permanent lock" issue. I don't know if it's a problem with the MacOS "dual fork" file structure fighting with the Microsoft temporary lock file.
I've re-pushed NTFS permissions down from the parent folder to see if that would resolve the creation/destruction of the temporary files. It works for a bit then the problem comes right back.
We have even had one file where all permissions were removed and even the SYSTEM user was unable to recover the permissions. I couldn't seize ownership with the GUI or any cmd commands. I had to restore the file from a backup.
Have you had any luck with this issue?
I've tested the glitch with a laptop that is running the same versions of MacOS and Office but have been unable to trigger the lock file issue.