Ok then. Someone in the comments mentioned that there is a fix which is included in Ubuntu 10.04 and also available via PPA for ubuntu 9.10. Whatever made you write this, Gijs Molenaar , it is not fixed. It's still not fixed within samba if you look at the status of the bug over there at samba (https://bugzilla.samba.org/show_bug.cgi?id=6888). However I appreciate your actions (to find the upstream original bug description and even do the package making!!) - this should have helped a lot of people - but in this case unfortunately doesn't --> so please *before* you claim it's fixed - test it . Under the conditions which are described in the bug description. Even if the samba people say it is. In this case - I repeat - it is not. Which brings me to a second note: Chuck Short - almost immediately after I filed this bug (as a Samba bug) you enhanced it in order to be a Cups bug as well. But why? This confuses the devs, this doesn't help anyone. As I described and other people told: It *works* with windows clients (32 bit), it works with linux *clients* - heck - it even works with Windows 7 if you redirect LPT1 or create a direct IP connector. Which is not stable (for Windows specific reasons). But it works for a moment. It is so overwhelming clear, that this is Samba in the first place. Why CUPS then? If a Cups dev/packager comes and sees what is actually going on... he will turn his back, mumbling that this is something for the samba guys. If a Samba developer comes in he will realize that this is filed under "Cups" - so he will say that in the first place the cups guys are responsible. And in the end there is the result: Deadlock. That's why I wont change the hint that "a fix is released"for the "cups"-filed version . Please read carefully, what Crazydave is writing (I discussed some things with him behind the scenes) - he has very precise experiences with this bug and above my description he even focuses on automatic driver rollout mechanisms which work fine (!!) with Windows 32 Bit Clients - but not with windows 64bit clients.
What about SMB2 ? (http://en.wikipedia.org/wiki/Server_Message_Block --> "Microsoft introduced SMB2 with Windows Vista in 2006."). I remember that samba had a hard time and needed more than half a year to make Vista 32 bit clients speak to printer shares. Maybe in 64bit space some parameters of the SMB2 implementation are different. This is something for upstream samba tough. All in all - I am out. I have no time to do further things here. Which is because I do not depend on Windows anymore (I had a very new AMD GFX card back when I filed the bug, that's why I was on Windows7 with one of my PCs back then when I filed the bug). Good luck to dave and the others figuring this out. Maybe someone should compare this to a different Linux (maybe rolling-release distros like Arch or Gentoo) which may have a more up to date package of samba (and well - cups). Even better: A fresh from SVN sources compiled samba - all this to compare things. Just to make sure first of all if this is Ubuntu related or upstream related. Right now it feels more upstream related for me. Again: I do not have the time to check this out. Now my ending sentence: Gijs - once more - it is great, what you did by doing all that packaging with all the knowledge necessary collected from the samba folx. Thanks a bunch and keep the spirit - just tell people that you *think* that's it and tell them, they should test it to make sure it really is. Good luck, Herr Irrtum! ** Changed in: samba (Ubuntu) Status: Fix Released => Incomplete -- Samba shared printers not accessible under Vista and Windows7 https://bugs.launchpad.net/bugs/482836 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to samba in ubuntu. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
