Non-default wallpapers are not readable by Unity-Greeter

Bug #928553 reported by Jason Warner on 2012-02-07
This bug affects 98 people
Affects Status Importance Assigned to Milestone
gnome-control-center (Ubuntu)
unity-greeter (Ubuntu)

Bug Description

I use a non-default wallpaper and it is a different folder than the default wallpapers. By default, the permissions on this are not readable by Unity-Greeter. With the new unity-greeter switching, I would expect that if I choose a wallpaper, it would get copied somewhere (~/.background ?) with the correct permissions for Unity-Greeter or some other mechanism that gets me the added Unity-Greeter functionality.

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: gnome-control-center 1:3.2.2-2ubuntu6
ProcVersionSignature: Ubuntu 3.2.0-14.23-generic 3.2.3
Uname: Linux 3.2.0-14-generic x86_64
NonfreeKernelModules: nvidia wl
ApportVersion: 1.91-0ubuntu1
Architecture: amd64
Date: Wed Feb 8 09:58:23 2012
InstallationMedia: Ubuntu 11.10 "Oneiric Ocelot" - Release amd64 (20111012)
SourcePackage: gnome-control-center
UpgradeStatus: Upgraded to precise on 2012-02-01 (6 days ago)
 deja-dup 21.2-0ubuntu4
 gnome-bluetooth 3.2.1-1ubuntu5
 indicator-datetime 0.3.1-0ubuntu5

Jason Warner (jasoncwarner) wrote :
description: updated
Changed in unity-greeter (Ubuntu):
status: New → Triaged
importance: Undecided → Low
Changed in gnome-control-center (Ubuntu):
status: New → Triaged
importance: Undecided → Low
Changed in gnome-control-center (Ubuntu):
assignee: nobody → Canonical Desktop Team (canonical-desktop-team)
Martin Pitt (pitti) wrote :

My gut feeling is that we should not do this. If you protect your files to not be world-readable, or they are on an ecryptfs container, the greeter should not subvert this and copy them to other places.

Changed in gnome-control-center (Ubuntu):
status: Triaged → Won't Fix
Changed in unity-greeter (Ubuntu):
status: Triaged → Won't Fix
Sebastien Bacher (seb128) wrote :

Well Martin the issue has been discussed a bit in another bug (looking for the number), even if the file is publicly available that doesn't work because gnome-desktop store your background in .cache which has permissions set to 700 by default so even if the image can be read the actual copy used and stored can't

Martin Pitt (pitti) wrote :

I this case, why doesn't the greeter fall back to reading the actual file instead of the cache?

Sebastien Bacher (seb128) wrote :

Well I guess that's what this bug is about ;-) The current implementation just store in accountsservice the url of the file used by the desktop which is in .cache, the fact that the dir is 700 and such not accessible to the greeter was probably overlooked

Martin Pitt (pitti) on 2012-02-08
Changed in unity-greeter (Ubuntu):
status: Won't Fix → Confirmed
status: Confirmed → Triaged
mstfa cmly (mstfacmly) wrote :

If I may, there is a fix to this, but it requres the use of gsettings or the Dconf editor.

If there was a way to parse the wallpaper file name as it is being set and send it to the gsettings command, this would be easily fixed.

The command would look like:
gsettings set org.gnome.desktop.background picture-urt 'file:://<full_path_name>'

Moustafa Chamli [2012-02-16 18:21 -0000]:
> If I may, there is a fix to this, but it requres the use of gsettings or
> the Dconf editor.

That's not the problem, and it wouldn't help. We know the name of the
wallpaper, but if the file is not accessible to the lightdm user it
still couldn't display it. Also, for e. g. an encrypted home directory
you can't read the gsettings either.

Martin Pitt |
Ubuntu Developer ( | Debian Developer (

mstfa cmly (mstfacmly) wrote :

Couldn't the Appearance setting tool have a script which would change the dconf value? I'm mainly saying it would be a workaround, having set the wallpaper myself from within the session.

That said, I haven't tried it for an encrypted Home directory, so I can't confirm it would fix it.

Fuad Hasan B (slifer2006-omega) wrote :

I don't really know what happen behind the hood, but when i use wallpaper with the same resolution as your monitor, the wallpaper change does work.

Any idea about this?

Sebastien Bacher (seb128) wrote :

The issue is coming quite often, we should try to figure if we want to "fix" things to display backgrounds from "public" dirs like the xdg Image user dir or not...

eric (obrowny06) wrote :

My monitor is 1280*1024
The image I want is 700*467 and is jpg.

If I am trying to change my wallpaper through system settings, and then disconnect, then my greeter on login is the pink one.

-Now go to your photo through nautilus
-open it with image viewer
- right click the same photo and choose "set as wallpaper" in the menu

disconnect and Tadaa !!! lightdm greeter is my background !!!!

Any clue ?

it didn't work with a picture that was 4000*3000...

CaptainMark (imark-skinner) wrote :

Is anyone using the encyrpted home directory option, would the chosen background need to be copied out of the home folder say /usr/share/backgrounds otherwise unity-greeter wouldnt be able to read the image even in .cache

Changed in gnome-control-center (Ubuntu Precise):
status: Won't Fix → In Progress
Sebastien Bacher (seb128) wrote :

the gnome-control-center update should fix the case where settings public local files was not working, it will probably not solve the non available files in the user dir cases

Changed in gnome-control-center:
importance: Unknown → Medium
status: Unknown → New
Carlo Piana (carlo-piana) wrote :

Most definitely, since this is a behaviour that annoys people and has an apparently unpredictable pattern (in reality, it's just that the partition is encrypted, but nothing prompts the user), this must be fixed.

So either you say "look, your backdrop is not going to be shown in the greeter, which will show the standard one" or you just take the plunge and copy the backdrop to /usr/share/something and let the damn thing bring it up.

zzecool (zzecool) wrote :

Lol i agree ;)

Agree with Carlo, lets just copy the image to '/usr/share/backgrounds-current' for example. We live in 2012, hard disk space is not that rare.

Sebastien Bacher (seb128) wrote :

Thanks but it's not very useful telling others what they "must" fix, there is lot to do, if you want to help patches are welcome

Copying would mean you would made any background public where users might not want to share their background

Hernando Torque (htorque) wrote :

Which is a moot point, since the original background file likely resides somewhere in ~/Pictures, which is world-readable by default.

nefyt (nefyt) wrote :

So... I just installed Precise and I saw this cool new feature of showing up the wallpaper in the login screen... I thought it was great until I used a custom wallpaper.... so I have this problem too. I have encrypted my home directory but I still want to show my non-default wallpaper (located in home/Images directory) in the login screen.

Please fix this. Perhaps an option in the background options window will resolve the "privacy" issues you guys have discussed here. The option would be something like "Show the wallpaper in the login screen" (check for yes or no). So if that option is set to yes, I guess the wallpaper file should then be copied to '/usr/share/backgrounds' (for example) so the login screen has always access to the file and show the wallpaper.

As for the comment of "Sebastien Bacher", which I assume he would also tell he same thing, I must say that I'm not a programmer but I'm sure Ubuntu programmers welcome suggestions, and that they won't take them like we (non-programmers) are telling them what to do without giving any "real help". Our help are the suggestions and bug reports.

Thank you for your time.

Alex Moldovan (alexmoldovan) wrote :

A workaround is to copy the desired wallpaper into /usr/share/backgrounds and rename it using one of the filenames of the default files found there:
$ sudo mv /usr/share/backgrounds/Delicate_Petals_by_lefthandgergo.jpg /usr/share/backgrounds/Delicate_Petals_by_lefthandgergo.bkp
$ sudo cp ~/Pictures/a-blue2.jpg /usr/share/backgrounds/Delicate_Petals_by_lefthandgergo.jpg
$ sudo chmod 644 /usr/share/backgrounds/Delicate_Petals_by_lefthandgergo.jpg

Now, opening System Settings -> Apperance should display your photo as Delicate_Petals_by_lefthandgergo.jpg

mohican (mohican) wrote :

By the way, default dynamic wallpaper (e.g. the blue stripes, changing with time) are not displayed either.

Maybe the first image (or the last used) should be displayed.

Bence Lukács (lukacs-bence1) wrote :

I realized, that this bug still exist in Quantal.
It has to be fixed for now...

Changed in gnome-control-center (Ubuntu Precise):
assignee: Canonical Desktop Team (canonical-desktop-team) → nobody
Changed in gnome-control-center (Ubuntu):
assignee: Canonical Desktop Team (canonical-desktop-team) → nobody
Changed in gnome-control-center (Ubuntu Precise):
status: In Progress → Triaged

Confirmed in Ubuntu 13.04 Raring Ringtail

Making my "images" folder readable by "other group" makes unity-greeter change it's background

Brice Terzaghi (terzag) wrote :

Still present in Saucy (and probably Trusty too?).

Zwylicht (zwylicht) wrote :

Yes, still present in Trusty :(

Changed in gnome-control-center:
status: New → Confirmed
Changed in gnome-control-center:
status: Confirmed → Expired
José Lou Chang (obake) wrote :

Is there anyone working on this bug?

Dario Bertini (berdario) wrote :

Personally, I haven't been affected by this bug anymore.

(Also, I stopped having my HOME encrypted, and now I use full disk encryption, which is a better solution anyhow)

Now, when you right click on an image and "Set as wallpaper", it'll get copied to ~/Pictures/Wallpapers this folder is world readable, so if the issue was with the folder, it's now solved. The file itself still retains its permissions, but I think this is on purpose.

If a custom wallpaper is added with the + button inside the control panel, the picture is not copied, so you'd need to workaround that manually.

I think all of this might still be an issue if the HOME is encrypted.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.