Could affected users who haven't already reported please report whether the workaround of adding "use client driver = no" works for you, or if it fails for you?
Assuming that "use client driver = yes" fixes the problem, it seems to me that this is a question about how the Windows printer driver concept works with samba. If we don't want to ever install Windows printer drivers into samba, then it would make sense for Ubuntu to enable "use client driver = yes" by default. If we do want to be able to install Windows printer drivers into samba, then we must have "use client driver = no" (the default) in smb.conf by default. If my understanding is correct, then users can: 1) Set "use client driver = yes" and install printer drivers locally on each Windows client manually. 2) Set "disable spoolss = yes" and downgrade samba's behaviour to older printing protocols, which do not support server-side storage of Windows printer drivers. 3) Install a Windows printer driver into samba for each printer for which sharing is required, which is how printing works on Windows servers. This is documented but is a bit involved to set up, but it does provide the cleanest and most functional printing experience to Windows users. So what should the default be? The current packaging does provide defaults to permit the beginnings of option 3, and changing the default to option 1 would break this. ** Changed in: samba (Ubuntu) Importance: Undecided => Medium -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to samba in Ubuntu. https://bugs.launchpad.net/bugs/990388 Title: acces denied samba printer shares after upgrade precise To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/990388/+subscriptions -- 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
