Announcement

Collapse
No announcement yet.

Login Panel will not accept my custom image in Kubuntu 14.04.

Collapse
This topic is closed.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Login Panel will not accept my custom image in Kubuntu 14.04.

    I forgot to include the word Background when I wrote the subject of this post. It is not my image that won't appear, it is my custom background image.

    When I login, the screen is completely white with fonts in black. Additionally, I have dual monitors, and one appears a clone of the other; the cursor moves on both screens at the selfsame time in the same locations on the screen. This happens, when the login screen is showing. When the system finally completes the boot process, my custom background appears and the cursor is able to move from screen to screen.

    I have had my custom image on my Kubuntu 14.04 for quite some time now, perhaps a year. When, in System Settings, I try to establish my image, it appears to apply, however when I restart the computer, the white screen with black font appears.

    I have shut down the computer completely and drained all memory to see if that might help; it did not help.

    Any ideas, anyone?
    Last edited by Shabakthanai; Dec 18, 2015, 04:43 AM.

    #2
    One possible cause for a white screen instead of a custom image in the sddm login greeter is permissions/ownership of the custom image. The greeter runs as the user "sddm" (not as a "regular_user" or "root"), so it might not have read access to everything owned by the regular_user. This problem does not extend to the config dialog (which does not run as user "sddm") so the image might show fine in the preview.

    If you do not know how to troubleshoot the permissions, post the output of the command:
    Code:
    namei -l /path/to/the/background/image
    (obviously replace "/path/to/the/background/image" with the actual path)
    And someone can have a look at it.

    EDIT: Hmm...not sure if 14.04 has sddm as the greeter, but the same goes for lightdm (so the troubleshooting steps are the same).
    Last edited by kubicle; Dec 18, 2015, 04:55 AM.

    Comment


      #3
      steven@stevenK15:~$ namei -l /path/to/the/background/image
      f: /path/to/the/background/image
      drwxr-xr-x root root /
      path - No such file or directory
      steven@stevenK15:~$

      Comment


        #4
        Originally posted by Shabakthanai View Post
        steven@stevenK15:~$ namei -l /path/to/the/background/image
        f: /path/to/the/background/image
        drwxr-xr-x root root /
        path - No such file or directory
        steven@stevenK15:~$
        You missed this part of my post:
        replace "/path/to/the/background/image" with the actual path

        Comment


          #5
          yes, both lightdm and sddm need to have the image located somewhere outside of any users' home folder. I put mine in /usr/share/wallpapers, so I might remember where I put them easier.

          Comment


            #6
            Originally posted by claydoh View Post
            yes, both lightdm and sddm need to have the image located somewhere outside of any users' home folder. I put mine in /usr/share/wallpapers, so I might remember where I put them easier.
            Technically, it isn't about the location, but the permissions. An image will work if user lightdm/sddm has read access to it even if it's under a user's $HOME, and won't work outside of $HOME if user lightdm/sddm doesn't have read access.

            In practice, the location may indirectly affect the permissions (as read permissions to the file won't be enough if there is no read access to the directory that holds it, for example), and standard ownership/permission settings can be (and usually are) different in $HOME and outside of it.

            The general fix is still allowing user lightdm/sddm to have read access to the image file (moving the image file under /usr/share/wallpapers/ can be one way of accomplishing that, but you may still need to edit the permissions of the file...if it's not readable for all users).

            Comment


              #7
              yes, the "users" sddm and lightdm do not have read access to users' home folders, but do have it in most elsewhere. I've not had to edit permissions to do this, ever.

              Comment


                #8
                Originally posted by claydoh View Post
                yes, the "users" sddm and lightdm do not have read access to users' home folders,
                Depends on what your permissions are for user's home (or to the directory path of the file), and you can always give them read access if they don't have it

                Originally posted by claydoh View Post
                but do have it in most elsewhere. I've not had to edit permissions to do this, ever.
                This depends on what the permissions are for the original (to be copied) image file, the method of copying (whether it preserves permissions or not) and to some extent on the umask of the target user.

                If, for example, the image file has 0640 permissions (-rw-r-----) and you copy it to /usr/share/wallpapers with 'sudo cp', it will still have 0640 permissions in the new location (which means the file won't be readable for "other" users and won't work with lightdm/sddm).

                Copying the image under /usr may (and often does) work, but you can't ignore the permissions. You still need to make sure it's readable for "other" users.
                Last edited by kubicle; Dec 26, 2015, 05:44 AM.

                Comment


                  #9
                  My turn to get embarrassed again. Thanks guys. I found the folder that contains wallpapers. My custom wallpaper was not in there, so I used the option to select my own wallpaper and entered the default wallpaper. I now have a default appearance system and the knowledge to be able to add my chosen wallpaper whenever I want. I am starting to remember things I forgot. You guys are so wonderful and patient with me. Cudos, Shab

                  Comment

                  Working...
                  X