[SOLVED] warning: directory permissions differ on var/log/wicd/

Hi,
I've seen several posts about this but I couldn't really figure out what's the appropriate action. Well, anyway I get the following error message when doing a pacman -Syu
warning: directory permissions differ on var/log/wicd/
filesystem: 1363 package: 755
Is it a bug? Should I change the filepermission of the directory, and if so to what?
Last edited by OMGitsUGOD (2009-09-18 10:38:32)

This is sort of related,
http://bbs.archlinux.org/viewtopic.php?pid=432588
or at least thats the post at the end has the same file permisions as I have in /var/log/wicd.
$ ls -la /var/log/ | grep wicd
d-wxrw--wt 2 root root 4096 2009-08-27 07:58 wicd
I'm pretty bad at this stuff, but isn't this rather 1361 than 1363, or am I totally wrong? And why not allow theowner to read the file?
Last edited by OMGitsUGOD (2009-09-17 08:43:32)

Similar Messages

  • GDM update: directory permissions differ on /var/log/gdm/

    Hello,
    Running Arch 64Bits kernel 3.9.9-1 with systemd and i got the following warning during a gdm update today:
    (1/6) upgrading libgdm [######################] 100%
    (2/6) upgrading gdm [######################] 100%
    warning: directory permissions differ on /var/log/gdm/
    filesystem: 711 package: 1770
    Why would gdm need some 1770 permissions for log files? Looks pretty suspicious to me, especially the sticky bit thing. What did i miss?
    PS: BTW the update is successful (it's a warning afterall, not an error)
    Thanks
    EDIT:
    Looks like the opposite situation than 3 years ago:
    https://bbs.archlinux.org/viewtopic.php?id=94681
    https://bugs.archlinux.org/task/19294
    EDIT2: here's what i have in /var/log:
    msytux666 var # ls -la
    total 64
    drwxr-xr-x 14 root root 4096 Jul 6 15:34 .
    drwxr-xr-x 20 root root 4096 Jul 16 20:24 ..
    -rwxrwxrwx 1 root root 4192 Jun 19 11:27 .com.zerog.registry.xml
    drwxr-xr-x 7 root root 4096 Jul 7 00:07 abs
    drwxr-xr-x 8 root root 4096 Jun 16 17:28 cache
    drwxr-xr-x 3 root root 4096 Jun 17 19:07 db
    drwxr-xr-x 2 root root 4096 May 31 20:40 empty
    drwxrwxr-x 2 root games 4096 May 31 20:40 games
    drwx--x--x 2 gdm gdm 4096 Jun 15 14:23 gdm
    drwxr-xr-x 26 root root 4096 Jul 16 01:13 lib
    drwxr-xr-x 2 root root 4096 May 31 20:40 local
    lrwxrwxrwx 1 root root 11 May 31 20:40 lock -> ../run/lock
    drwxr-xr-x 6 root root 4096 Jul 18 00:33 log
    lrwxrwxrwx 1 root root 10 May 31 20:40 mail -> spool/mail
    drwxr-xr-x 2 root root 4096 May 31 20:40 opt
    lrwxrwxrwx 1 root root 6 May 31 20:40 run -> ../run
    drwxr-xr-x 6 root root 4096 Jun 16 17:28 spool
    drwxrwxrwt 8 root root 4096 Jul 18 00:33 tmp
    gdm is owned by gdm, so why would it needs 1770 permissions?
    EDIT3:
    After further research i appear the way gdm is installed may matter.
    Well i installed gdm through pacman and always update it with pacman as well. Never manually compiled/make_install'd it nor used abs for it.
    Last edited by BGK (2013-07-19 21:37:13)

    Okay I'm confused ...
    Commit:https://projects.archlinux.org/svntogit … 92c38d536d
    @@ -68,8 +68,7 @@ package_gdm() {
    cd $pkgbase-$pkgver
    make DESTDIR="$pkgdir" install
    - chmod 1770 "$pkgdir/var/log/gdm"
    - chmod 700 "$pkgdir/var/lib/gdm/.config/dconf"
    + chmod 711 "$pkgdir/var/log/gdm"
    rm -r "$pkgdir/var/run" "$pkgdir/var/gdm"
    ### Split libgdm
    so that takes away the 1770 permissions, and replaces them with 711. 
    @@ -5,6 +5,7 @@ post_install() {
    getent passwd gdm > /dev/null 2>&1 || usr/sbin/useradd -c 'Gnome Display Manager' -u 120 -g gdm -d /var/lib/gdm -s /sbin/nologin gdm
    passwd -l gdm > /dev/null
    chown -R gdm:gdm /var/lib/gdm > /dev/null
    + chown root:gdm /var/log/gdm > /dev/null
    glib-compile-schemas /usr/share/glib-2.0/schemas
    gtk-update-icon-cache -q -t -f /usr/share/icons/hicolor
    however:
    chown root:gdm /var/log/gdm > /dev/null
    .. is where I get confused.  This command makes root and the group gdm the new owners of /var/log/gdm, or did I go wrong somewhere?

  • What to do about warning "directory permissions differ on..." ?

    Hello!
    I have gotten this warning when upgrading today:
    warning: directory permissions differ on var/run/gdm/
    filesystem: 1775  package: 711
    warning: directory permissions differ on var/log/gdm/
    filesystem: 1770  package: 755
    This means that the permissions on my computer didn't match with the ones from the package being upgraded/installed, right?
    Which permissions should I leave for that folder (var/log/gdm/) and why? And why is the warning on there twice with different values? i'm confused
    Last edited by trusktr (2010-04-06 18:07:37)

    trusktr wrote:
    Hello!
    I have gotten this warning when upgrading today:
    warning: directory permissions differ on var/run/gdm/
    filesystem: 1775  package: 711
    warning: directory permissions differ on var/log/gdm/
    filesystem: 1770  package: 755
    This means that the permissions on my computer didn't match with the ones from the package being upgraded/installed, right?
    Which permissions should I leave for that folder (var/log/gdm/) and why? And why is the warning on there twice with different values? i'm confused
    If you or another package had good reason to change it, leave it at its current value. If not, change it to the package value listed above (and see if anything breaks).
    You're seeing different permissions for two different folders: read the warnings more closely.

  • Directory permissions differ on var/

    When upgrading packages with pacman, I've been getting a warning that "directory permissions differ on var/  filesystem 775 package 755
    This most recently was during my upgrade of xorg-server
    I'm not sure what causes this warning, or whether some action needs to be taken, and if so, which way to change things.....:(

    http://bbs.archlinux.org/viewtopic.php?id=42314

  • Warning: directory permissions differ

    I am getting an error when downloading and installing packages with pacman.
    This is what I get:
    $ sudo pacman -S nitrogen
    warning: nitrogen-1.2-1 is up to date -- reinstalling
    resolving dependencies...
    looking for inter-conflicts...
    Targets: nitrogen-1.2-1
    Total Download Size: 0.00 MB
    Total Installed Size: 0.13 MB
    Proceed with installation? [Y/n]
    checking package integrity...
    (1/1) checking for file conflicts [#####################] 100%
    (1/1) upgrading nitrogen [#####################] 100%
    warning: directory permissions differ on usr/man/man1/
    filesystem: 755 package: 700
    I don't know if that has a serious impact, but I am sure it shouldn't be like that...

    Snowman wrote:Submit a bug report.
    This is one way and i hope it helps you and the other devs. But what do you think about that the systems can repair this by itselfs? On my opensuse server i have a tool named chkstat which runs as a cronjob and set the file permissions as loaded from a file.
    Source: http://ftp.gwdg.de/pub/opensuse/distrib … 11.src.rpm
    manpage: http://www.trinler.de/de/linux/man.html?command=chkstat
    The advantage from my side is that one or a group of devs define the file permissions standard for arch linux and everyone can choose to use it or to append own more or less secure/paranoid settings. Another sideeffect is that every dev can take a look inside this config file to see what permission the own PKGBUILD need so that in the best case we will not see such messages in the future. The source includes config files so there is no need to restyle this all from zero.

  • [SOLVED] Need Help Understanding Warning on Directory Permissions

    Hi guys-
    In my last update I got these warnings:
    warning: directory permissions differ on /usr/share/polkit-1/rules.d/
    filesystem: 700 package: 755
    warning: directory permissions differ on /var/lib/libvirt/qemu/
    filesystem: 755 package: 770
    I've seen quite a few threads floating around like these, but they just add to my confusion. I have not changed persmissions to these files. From what I've gathered so far from a few threads is that the package handler may have changed persmissions resulting in the warning messages. This is where my confusion sets in, and I don't know if it's from staring at the screen for too long, but if I cd into those directories and ls -l, there's the rules.d directory with 700:
    /usr/share/polkit-1/:
    total 8
    drwxr-xr-x 2 root root 4096 Jun 14 10:39 actions
    drwx------ 2 polkitd root 4096 Jun 16 18:31 rules.d
    However, if I cd into rules.d, there's two files in there, both with 644 permissions:
    total 8
    -rw-r--r-- 1 root root 281 Jun 1 02:17 50-libvirt.rules
    -rw-r--r-- 1 root root 488 May 12 17:11 gnome-control-center.rules
    Where's the file with 755?
    Same thing with the other wanring. There's qemu with 755. Libvirt is 755. The directory inside qemu is empty. Where's 770?
    total 36
    drwxr-xr-x 2 root root 4096 Mar 2 05:39 boot
    drwxr-xr-x 2 root root 4096 Mar 2 05:39 dnsmasq
    drwxr-xr-x 2 root root 4096 Mar 2 05:39 filesystems
    drwxr-xr-x 2 root root 4096 Mar 2 05:39 images
    drwxr-xr-x 3 root root 4096 Mar 2 05:39 lockd
    drwxr-xr-x 2 root root 4096 Mar 2 05:39 lxc
    drwxr-xr-x 2 root root 4096 Mar 2 05:39 network
    drwxr-xr-x 2 root root 4096 May 10 19:05 qemu
    drwxr-xr-x 2 root root 4096 Mar 2 05:39 uml
    Can someone help me understand this please?
    Last edited by w201 (2015-06-17 03:23:03)

    The message does indeed mean that the package maintainer has changed the permissions on those directories. You can change your directories to match or leave them as-is. I always change mine when I get messages like this. To do that in this case, you'd run:
    chmod 755 /usr/share/polkit-1/rules.d
    chmod 770 /var/lib/libvirt/qemu
    That will make your directories consistent with the new versions of the packages.

  • Libvirt permissions differ on upgrade

    (12/16) upgrading libvirt [--------------------------------] 100%
    warning: /etc/libvirt/qemu/networks/default.xml installed as /etc/libvirt/qemu/networks/default.xml.pacnew
    warning: directory permissions differ on /var/lib/libvirt/qemu/
    filesystem: 755 package: 770
    >>> You may need to run 'rm -rf ~/.libvirt'
    Does pacman just never update permissions automatically?  Anyway I just manually changed it with the following command.  Hope that was the right call.
    $ sudo chmod 770 /var/lib/libvirt/qemu/

    Directory permissions are never changed automatically. A directory could be part of two different packages, with each package specifying different permissions. To make the job easier pacman only warns about changed directory permissions. File permissions are another matter, they will be modified.
    You did the right thing with changing the permissions if the 755 wasn't set by you manually.

  • Solved: pacman - permissions differ on tmp/

    Not sure if anyone else is seeing this because this may have been part of something I did a way back.  I'm getting:
    ( 35/400) upgrading filesystem [######################] 100%
    warning: directory permissions differ on tmp/
    filesystem: 777 package: 1777
    I know a bit about the filesystem package.  If I remember correctly it contains files that are Arch specific like the boot scripts...  Now if I'm reading this correctly the 777 permissions of "filesystem" is original directory and "package" is the package's permissions for the tmp directory.  Here's my /tmp directory permissions after the update:
    drwxrwxrwt 11 root root 4.0K Sep 13 11:41 tmp
    Can anyone help me clarify this?  Is the problem now fixed, or is there something I need to do?
    Last edited by Gen2ly (2010-09-13 19:49:14)

    I haven't seen pacman changing permission on directories yet, but according to the message, your /tmp didn't have the sticky bit set before the upgrade. Though things will work fine with just 777, not having the sticky bit on /tmp will mean that someone could delete and replace files owned by someone else, which is a security risk.

  • [SOLVED] Clarify - directory ownership differs during sysmd upgrade

    Hello,
    I get the warning (see below) - and I am wondering if I understand it correctly that I do not need to do anything about this warning?
    warning: directory ownership differs on /var/log/journal/remote/
    filesystem: 0:998 package: 0:0
    It is the same warning discussed in this thread: https://bbs.archlinux.org/viewtopic.php?id=193782, and since it is solved,
    and the bug report here: https://bugs.archlinux.org/task/43852 also does not give me a conclusive answer, I opened this one.
    Regards
    Martin
    Last edited by onslow77 (2015-02-21 12:12:20)

    Hello,
    I tried to solve this by doing:
    1. Checking the systemd package
    pacman -Qkk systemd
    warning: systemd: /var/log/journal/remote (GID mismatch)
    2. Change the "/var/log/journal/remote" to the root group and user
    # chown root:root /var/log/journal/remote/
    3. Checking the systemd package again
    pacman -Qkk systemd
    systemd: 1003 total files, 0 altered files
    4. Seems correct, so I rebuild my initramfs and reboot (hoping this will keep the above chown edit)
    # mkinitcpio -p linux
    # reboot
    Checking the systemd package again
    pacman -Qkk systemd
    warning: systemd: /var/log/journal/remote (GID mismatch)
    So after my reboot I am back where I started - and I do not get it, what am I suppose to to with this warning, point me in the right direction please.
    Regards
    Martin

  • Mercury Install, directory permissions

    [s3kt0r@localhost ~]$ sudo pacman -S mercury
    resolving dependencies...
    looking for inter-conflicts...
    Targets (1): mercury-1.9.5-1
    Total Download Size: 7.99 MB
    Total Installed Size: 10.97 MB
    Proceed with installation? [Y/n] y
    :: Retrieving packages from community...
    mercury-1.9.5-1-i686 8.0M 311.8K/s 00:00:26 [################################################################################################################################] 100%
    checking package integrity...
    (1/1) checking for file conflicts [################################################################################################################################] 100%
    (1/1) installing mercury [################################################################################################################################] 100%
    warning: directory permissions differ on usr/bin/
    filesystem: 755 package: 700
    warning: directory permissions differ on usr/share/gnome/
    filesystem: 755 package: 700
    warning: directory permissions differ on usr/share/icons/
    filesystem: 755 package: 700
    warning: directory permissions differ on usr/share/pixmaps/
    filesystem: 755 package: 700
    Anyway to fix this?  Thanks

    well 700 on /usr/bin looks like a very bad idea and could indeed partially wreck the system if these permissions were used. (but well, this should all be easily fixable as root).
    But permissions of existing directories are not changed.
    They would only be used if mercury was the very first package installed on a completely empty system. And this would probably never happen in real-world usage.
    So basically, when you have this warning, you do the following :
    1) if filesystem permissions are the correct ones, you are fine. just report a bug for the offending package
    2) if filesystem permissions are the wrong ones, you might want to fix it manually
    3) if you don't know, you can either just ignore the issue, or look for information, or ask around

  • Permissions differ

    Where can I find out what this means
    group differs on "dev" should be 0, group is 20
    permissions differ on "dev"should be dr-xr-xr-x they are drwxr-xr-x
    permissions on "private/var/log/secure.log should be rw----.th...?
    And what to do about it?

    Hi Anthony Jefferies,
    I have the same thing esp.( after using dreamweaver mx 2004 on 10.4.11.)
    I use the repair option on the disc ! and find that it fixes the issue until i run dreamweaver mx again !
    Good luck !

  • [SOLVED]Couldn't open file for 'Log debug file /var/log/tor/debug.log'

    Hello,
    I'm trying to run a tor relay on my arch linux box. Trying to launch the tor daemon, here's the log via
    $ systemctl status tor.service
    May 20 11:53:10 arch tor[21726]: May 20 11:53:10.877 [notice] Tor v0.2.4.21 (git-505962724c05445f) running on Linux with Libevent 2.0.21-stable and OpenSSL 1.0.1g.
    May 20 11:53:10 arch tor[21726]: May 20 11:53:10.877 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
    May 20 11:53:10 arch tor[21726]: May 20 11:53:10.877 [notice] Read configuration file "/etc/tor/torrc".
    May 20 11:53:10 arch tor[21726]: May 20 11:53:10.909 [notice] Opening Socks listener on 127.0.0.1:9050
    May 20 11:53:10 arch tor[21726]: May 20 11:53:10.909 [notice] Opening OR listener on 0.0.0.0:9798
    May 20 11:53:10 arch tor[21726]: May 20 11:53:10.000 [warn] Couldn't open file for 'Log debug file /var/log/tor/debug.log': Permission denied
    May 20 11:53:10 arch tor[21726]: May 20 11:53:10.000 [notice] Closing partially-constructed Socks listener on 127.0.0.1:9050
    May 20 11:53:10 arch tor[21726]: May 20 11:53:10.000 [notice] Closing partially-constructed OR listener on 0.0.0.0:9798
    May 20 11:53:10 arch tor[21726]: May 20 11:53:10.000 [warn] Failed to parse/validate config: Failed to init Log options. See logs for details.
    May 20 11:53:10 arch tor[21726]: May 20 11:53:10.000 [err] Reading config failed--see warnings above.
    May 20 11:53:10 arch systemd[1]: tor.service: main process exited, code=exited, status=255/n/a
    May 20 11:53:10 arch systemd[1]: Unit tor.service entered failed state.
    Why the tor daemon cannot write into /var/log/tor/debug.log ?
    Here's my /etc/group
    root:x:0:root
    bin:x:1:root,bin,daemon
    daemon:x:2:root,bin,daemon
    sys:x:3:root,bin
    adm:x:4:root,daemon,nue
    tty:x:5:
    disk:x:6:root
    lp:x:7:daemon
    mem:x:8:
    kmem:x:9:
    wheel:x:10:root,nue
    ftp:x:11:
    mail:x:12:
    uucp:x:14:
    log:x:19:root
    utmp:x:20:
    locate:x:21:
    rfkill:x:24:
    smmsp:x:25:
    http:x:33:
    games:x:50:
    lock:x:54:
    uuidd:x:68:
    dbus:x:81:
    network:x:90:
    video:x:91:
    audio:x:92:
    optical:x:93:
    floppy:x:94:
    storage:x:95:
    scanner:x:96:
    power:x:98:
    nobody:x:99:
    users:x:100:
    systemd-journal:x:190:
    nue:x:1000:
    avahi:x:84:
    lxdm:x:121:
    polkitd:x:102:
    git:x:999:
    transmission:x:169:
    vboxusers:x:108:
    tor:x:43:
    mysql:x:89:
    Last edited by giuscri (2014-05-20 12:18:56)

    SidK wrote:You must have modified your torrc to print to that log file. systemd starts the service as the tor user (see /usr/lib/systemd/system/tor.service). So if if you want to log to a file the tor user must have write access to it. By default however tor it set to log to the journal, which doesn't require any special permissions.
    Yes. I did edit the torrc file since I wanted the log to be store in that file. Indeed
    ## Logs go to stdout at level "notice" unless redirected by something
    ## else, like one of the below lines. You can have as many Log lines as
    ## you want.
    ## We advise using "notice" in most cases, since anything more verbose
    ## may provide sensitive information to an attacker who obtains the logs.
    ## Send all messages of level 'notice' or higher to /var/log/tor/notices.log
    #Log notice file /var/log/tor/notices.log
    ## Send every possible message to /var/log/tor/debug.log
    Log debug file /var/log/tor/debug.log
    ## Use the system log instead of Tor's logfiles
    Log notice syslog
    ## To send all messages to stderr:
    #Log debug stderr
    I missed the file systemd uses to choose who's the process owner.
    Course, I could edit /usr/lib/systemd/system/tor.service such that root will become the process owner; or, I could add the user I use everyday in the root group, then change the permission of /var/log/tor/debug.log such that it will be writable also for the folks in the root group.
    Yet they both seems to be a bit unsafe ...
    What is the best choice, to you guys?
    Thanks,

  • How can I fix this permissions "Library/Printers-should be 80 group is 0. Permissions differ. And User differs on "private/var/db/displaypolicyd" should be 0; Group is 244?

    How can I fix this on my 2014 iMac, please?
    Verifying permissions for “Macintosh HD”Group differs on “Library/Printers/InstalledPrinters.plist”; should be 80; group is 0.Permissions differ on “Library/Printers/InstalledPrinters.plist”; should be -rw-rw-rw- ; they are -rw-r--r-- .User differs on “private/var/db/displaypolicyd”; should be 0; user is 244.Group differs on “private/var/db/displaypolicyd”; should be 0; group is 244.
    I run the "fix" and it seemingly does, but if I verify permissions again later it returns.
    Thank you!

    It's not an error but an informative message that you can safely ignore. it's innocuous.

  • Warning:  SUID File (11 Files) and "Permissions Differ" - No Install Disc

    Hello,
    Have had my black macbook for about 3 1/2 years now (leopard) and having problems with it being really sluggish and freezing up. Additionally, the fan is coming on a lot and being really loud. I have checked activity monitor (all processes) and nothing is running over 12...Question is are the "warning suid files" and "permissions differ" the source of these problems? I can't find my original install disc (have one for my i mac but no good I hear.) Guessing I need to go to the genius bar to fix this issue...Thanks, PoorGradStudent

    Hello and welcome to the discussions, Those warning are normal and nothing to worry about.
    While your at the genius bar see if they will run a diagnostics test on your laptop. Note, if your problems only show up after it has been on for an hour, get there an hour early and warm it up.
    No use in have them look at it if you can't replicate the problem.
    Cheers,
    Glynn

  • Why does the directory ~/var/log keep appearing?

    It doesn't matter how many times I delete it, every few hours the blank directory ~/var/log gets created on my computer.
    I think it may have something to do with my Brother HL2170W printer, which is connected to my wifi network. But that's just from the fruitless googling on this topic I've already done.
    Does anyone know why a blank ~/var/log directory would persistently appear?
    Thank you in advance.

    ~var/log/ is a directory that holds log files. If it actually has a ~ in the name, some software is trying to write to the hidden directory, but has been miss-configured and is creating the directory you see instead of writing to /Users/username/var/log. ~/ is short for your home folder, but the program is actually writing that as part of the path name instead of being a path.

Maybe you are looking for