Python Samba:用户凭据未通过(cli_init_creds)?
我目前在 Ubuntu 中访问 Windows 打印共享时遇到问题(在工作中,所以我无法真正访问它们的设置),所以我最终开始研究 Gnome 的 '< code>system-config-printer' 这是用 Python 编写的,并使用 Python smbc
Samba 绑定。
我基本上已经成功地将我的问题归结为这段代码,该代码来自 /usr/share/system-config-printer/pysmb.py
,并且我在 python 中运行
命令行 shell:
import smbc, os
def do_auth (svr, shr, wg, un, pw):
return ("myworkdomain.com", "MYWORKUSERNAME", "MYWORKPASSWORD")
ctx = smbc.Context (debug=10, auth_fn=do_auth)
f = ctx.open ("smb://%s/%s" % ("printserver.myworkdomain.com", "PRINTSHARENAME"), os.O_RDWR, 0777)
第一个(某种程度上)问题是,在执行 ctx = smbc.Context... 行时,Python 总是抱怨:
params.c:OpenConfFile() - Unable to open configuration file "/home/MYUSERNAME/.smb/smb.conf":
No such file or directory
...但这也许不是真正的问题? (也许 smbc
应该重新创建此文件?)。
当然,最大的问题是我无法连接到共享:执行 f = ctx.open...
行后,有大量 Samba 通信转储,Windows 服务器似乎是交谈等 - 连接工作以失败告终:
SPNEGO login failed: Logon failure
cli_init_creds: user domain myworkdomain.com
session setup ok
map_errno_from_nt_status: 32 bit codes: code=c0000022
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
smbc.PermissionError: (13, 'Permission denied')
基本上,我对 Samba 知之甚少,无法阅读错误日志的其余部分,但我发现这一行:
cli_init_creds: user domain myworkdomain.com
...非常可疑 - 看起来好像 '< code>user' 有一个空字符串 - 即使我希望它是“MYWORKUSERNAME
”,如上面的“do_auth
”函数所指定!
请注意,此失败有点类似于我使用 cmdline smbclient
获得的 NT_STATUS_LOGON_FAILURE
(请参阅 获取 Windows 打印机共享 SMB 设置(用于Linux 上的 tsclient/rdesktop) - 超级用户),这是通过在命令行上明确指定 Windows 工作组来解决的 - 但是,我无法判断这是否也是 Python 情况下的问题;或者如果相反,用户名没有在这里传递(或者完全是第三种)。编辑:此工作命令行(列出共享)是(就本示例而言):
smbclient -L \\printserver.myworkdomain.com -U MYWORKUSERNAME -W myworkdomain.com
预先感谢您的任何建议,
干杯!
I am currently having a problem accessing Windows print shares (at work, so I don't reall have access to their settings) in Ubuntu, so I eventually got down to poking around the source of Gnome's 'system-config-printer
' which is written in Python, and uses the Python smbc
bindings for Samba.
I have basically managed to get down my problem to this piece of code, which comes from /usr/share/system-config-printer/pysmb.py
, and which I run in the python
command line shell:
import smbc, os
def do_auth (svr, shr, wg, un, pw):
return ("myworkdomain.com", "MYWORKUSERNAME", "MYWORKPASSWORD")
ctx = smbc.Context (debug=10, auth_fn=do_auth)
f = ctx.open ("smb://%s/%s" % ("printserver.myworkdomain.com", "PRINTSHARENAME"), os.O_RDWR, 0777)
The first (sort of) a problem is that upon the execution of the ctx = smbc.Context...
line, Python always complains:
params.c:OpenConfFile() - Unable to open configuration file "/home/MYUSERNAME/.smb/smb.conf":
No such file or directory
... but maybe that is not really a problem? (maybe smbc
is supposed to recreate this file anew?).
The big problem is, of course, that I cannot connect to the share: after executing the f = ctx.open...
line, there is a big dump of Samba communication, Windows server seems to be talking etc - and the connection effort finishes with failure:
SPNEGO login failed: Logon failure
cli_init_creds: user domain myworkdomain.com
session setup ok
map_errno_from_nt_status: 32 bit codes: code=c0000022
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
smbc.PermissionError: (13, 'Permission denied')
Basically, I know too little about Samba to be able to read the rest of the error log, but I find the line:
cli_init_creds: user domain myworkdomain.com
... very suspicious - it looks as if the 'user
' there is an empty string - even though I'd expect it to be 'MYWORKUSERNAME
', as specified by the 'do_auth
' function above!!
Note that this failure is somewhat similar to the NT_STATUS_LOGON_FAILURE
that I used to get with the cmdline smbclient
(see Obtaining Windows printer share SMB settings (for tsclient/rdesktop on Linux) - Super User), which was solved by explicity specifying a Windows workgroup on the command line - however, I cannot tell if that is also the problem here in the Python case; or if instead, the username is not passed here (or something completely third). EDIT: this working command line (which lists shares) is (in respect to this example):
smbclient -L \\printserver.myworkdomain.com -U MYWORKUSERNAME -W myworkdomain.com
Thanks in advance for any suggestions,
Cheers!
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
好吧,我想我终于明白了,感谢 错误#848065“system-config-printer 无法验证 Windows Samba 打印机,而 smbclient 可以 (cli_init_creds)” - 并查看 newprinter.py (来自
system-config-printer
)...但首先,有一点概述:
MYUSERNAME
MYWORKUSERNAME
MYWORKGROUP
的成员,该工作组还有一个子域myworkgroup.myworkdomain.com
printserver.myworkdomain.com
PRINTSHARENAME
好吧,事实证明,上面的
test.py
脚本中的一行是错误的 - 而不是:return ("myworkdomain.com", "MYWORKUSERNAME", "MYWORKPASSWORD" )
...应该有:
return ("MYWORKGROUP", "MYWORKUSERNAME", "MYWORKPASSWORD")
...(使用
MYWORKGROUP
在全部大写,Windows 的典型情况)
有趣的是,使用工作组子域不起作用:
return ("myworkgroup.myworkdomain.com", "MYWORKUSERNAME", "MYWORKPASSWORD")
。 ..因为它也会因“
smbc.PermissionError: (13, 'Permission returned')
”而失败(就像原始帖子示例一样)。解决“权限被拒绝”错误的一种方法是检查日志 - 它显示如下内容:
...显然,域名应该是:
作为参考,以下是“工作”设置中的日志片段(带有
return ("MYWORKGROUP" ...
):Ok, well, I think I finally got it, thanks to comments in Bug #848065 “system-config-printer cannot authenticate Windows Samba printer, while smbclient can (cli_init_creds)” - and reviewing newprinter.py (from
system-config-printer
)...But first of all, a little overview:
MYUSERNAME
myworkdomain.com
MYWORKUSERNAME
MYWORKGROUP
, which also has a subdomainmyworkgroup.myworkdomain.com
printserver.myworkdomain.com
PRINTSHARENAME
Well, it turns out that a single line in the
test.py
script above is wrong - instead of:return ("myworkdomain.com", "MYWORKUSERNAME", "MYWORKPASSWORD")
... one should have had:
return ("MYWORKGROUP", "MYWORKUSERNAME", "MYWORKPASSWORD")
... (with
MYWORKGROUP
in allcaps, as typical for Windows)Interestingly, using the workgroup subdomain does not work:
return ("myworkgroup.myworkdomain.com", "MYWORKUSERNAME", "MYWORKPASSWORD")
... as it will also fail with '
smbc.PermissionError: (13, 'Permission denied')
' (just like the original post example).One way to troubleshoot the "permission denied" error is to check the log - it shows something like this:
... apparently, the DomainName should be:
For reference, here is a snippet of the log from the "working" setup (with
return ("MYWORKGROUP" ...
):