Our repo is on a stornext SAN which about half our windows machines are connected to directly via fiber channel (so it is for all practical purposes a local disk) and the other half access it via samba share over 10GbE. Both map it to Z:
Today I did the 8.1.5.5-rc1 repository upgrade from 8.0.11.2 on a direct-connected machine (same as it was originally installed) and now when the monitor and slaves start on the ethernet (samba mount) machines, I get a dialog saying:
Could Not Connect To Deadline Repository
UnauthorizedAccessException: Read access is denied to directory ‘Z:/Deadline/DeadlineRepository8’
The launcher does start ok, and opening the logs from it I see this:
2017-02-07 16:56:13: Launching Slave: nvr-render-0001
2017-02-07 16:56:22: Error occurred while updating Repository Options: UnauthorizedAccessException: Read access is denied to directory ‘Z:/Deadline/DeadlineRepository8’ (Deadline.Configuration.DeadlineConfigException)
2017-02-07 16:56:32: Error occurred while updating Repository Options: UnauthorizedAccessException: Read access is denied to directory ‘Z:/Deadline/DeadlineRepository8’ (Deadline.Configuration.DeadlineConfigException)
2017-02-07 16:56:42: Error occurred while updating Repository Options: UnauthorizedAccessException: Read access is denied to directory ‘Z:/Deadline/DeadlineRepository8’ (Deadline.Configuration.DeadlineConfigException)
On the unix machine that exports the repo I’ve made sure perms are 777 and on the windows side I can navigate in the windows explorer into the repo just fine. In fact, in the error dialog, I can hit “Set Repository”, navigate into it and select it, but I continue to get this read access denied error. And just to be sure I created a simple text file with notepad in there with no trouble.
I do remember that on client installs I had to do “net use” from an elevated permission cmd shell to get the installer to be able to see the share (since that runs with elevated perms), so I quit the slave/monitor/launcher on this machine, did that, and relaunched, but still get the same error.
Any idea what this wants permission-wise different from a regular user accessing the repo folder? I’m out of ideas unfortunately and haven’t turned anything similar searching the forum.
Solved! In case anyone else hits this on a search someday…
I did a fresh repo install from a machine with the disk mounted via smb over ethernet, pointed deadline at that repo via the launcher, and was able to start a slave as normal. So I started digging for differences in the upgraded and fresh installs but outside of the jobs/backup dirs there were just minor differences in a few files that didn’t look relevant. (Below if anyone is curious.) I removed some .DS_Store garbage but as you’d expect that made no difference.
On a Windows machine direct-attached to the disk over fiber, the properties for the folder show Everyone having all but “special” permissions, just like everything else. But on further digging into the Windows “advanced” security settings I found that the upgraded repo had permissions set but the other one inherited. I’d always thought the samba share would only know about the unix perms for the connecting user, but clearly there’s more to it than I know. As soon as I made it inherit like others, the slaves on the machines mounting the disk over SMB started right up.
I don’t know that the upgrade did that. It’s quite possible it was like that already and something in the new version was sensitive to it that wasn’t before. At any rate, problem solved, so if you ever run into that error in the future, dig into those advanced security settings. It still seems strange that I could create files, read, and write there but Deadline couldn’t read it. If there’s anything you can do in the future to make that error more specific about what it is trying to read or how it’s accessing it exactly, or what ACL it needs that might help guide someone to the right fix more easily.
Cheers,
Matt
[root@postsan DeadlineTest]# for F in api balancer bin cloud custom draft events plugins pythonsync scripts settings submission vmx; do diff -qr …/Deadline/DeadlineRepository8/${F} ${F}; done
Only in …/Deadline/DeadlineRepository8/events/Shotgun: ShotgunUtils.pyc
Only in …/Deadline/DeadlineRepository8/plugins: TileAssembler
Only in …/Deadline/DeadlineRepository8/scripts: ._.DS_Store
Only in …/Deadline/DeadlineRepository8/scripts: .DS_Store
Only in …/Deadline/DeadlineRepository8/scripts/Jobs: CleanupTiles.py
Only in …/Deadline/DeadlineRepository8/scripts/Submission: TileSubmission.py
Only in …/Deadline/DeadlineRepository8/submission/3dsmax/Main: maxTileAssemblerCommand.ms
Files …/Deadline/DeadlineRepository8/submission/3dsmax/Main/SubmitMaxToDeadline_Defaults.ini and submission/3dsmax/Main/SubmitMaxToDeadline_Defaults.ini differ
Files …/Deadline/DeadlineRepository8/submission/3dsmax/Main/SubmitMaxToDeadline_StickySettings.ini and submission/3dsmax/Main/SubmitMaxToDeadline_StickySettings.ini differ
Only in …/Deadline/DeadlineRepository8/submission/Draft: Client
Only in …/Deadline/DeadlineRepository8/submission/Draft/Main: DraftIntegration.pyc
Only in …/Deadline/DeadlineRepository8/submission/Draft/Main: DraftSubmissionBase.pyc
Only in …/Deadline/DeadlineRepository8/submission/Nuke/Main: DeadlineGlobals.pyc
Only in …/Deadline/DeadlineRepository8/submission/Nuke/Main: SubmitNukeToDeadline.pyc
Only in …/Deadline/DeadlineRepository8/submission/Rhino/Client: loadToolbar.vbs
[