The /var
permissions are either a red herring or incidental. For the uid-to-name lookup to work, the following must be correct, in order:
/etc/nsswitch.conf
needs to have permissions 0644, owner root:root.
- The
passwd
entry in that file needs to be correct - given the very large IDs, you're probably not using just the local password file, but some ldap or AD setup? Make sure that it's listed, and listed early on.
- The service that actually provides your identities needs to be up and running and accepting your queries - for local users, that means that
/etc/passwd
must have permissions 0644 and owner root:root.
- The client library for your identity service may have permissions requirements for its config, cache, or both. This is where the
/var
permissions would come in, but without knowing more about what you use for authentication, that's not possible to troubleshoot. At a minimum, make sure that /var
itself has permissions 0755, owner root:root; directories it contains should be owned by either an obvious system user/group (e.g. "mail" for /var/mail
) or root, and not be world-writable (with the exception of /var/tmp
, if it exists, which should be root-owned and have permissions 1777).
If that doesn't help (and even if it does), please provide more information about your auth system - LDAP, samba, AD (via what?), or something else.
It seems to me that permissions are not correctly set.
you are user g
and can read a file = OK
but you can't create a file in a destination because the directory media
is not writeable by you, only root
can do that
So either copy as root
or change the permissions on target so that you have a write permission on media
directory.
As pointed out it's not possible to change permissions nor ownership on mounted NTFS filesystem. In that case there is a possibility to use proper mount options. Bellow excerpt from man mount
uid=value, gid=value and umask=value
Set the file permission on the filesystem. The umask value is given in octal. By default, the files are owned by root and not readable by somebody else.
Example: (for /dev/sdc1
with FAT32 filesystem)
Check that the device is not mounted (following should return without output)
$ mount | grep sdc1
Mount the device with uid
and gid
option set
$ sudo mount /dev/sdc1 -o uid=1000,gid=1000 /mnt
Verify the mountpoint
$ mount | grep sdc1
/dev/sdc1 on /mnt type vfat (rw,relatime,uid=1000,gid=1000,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
Best Answer
The
/sys
directory in Linux is deceptive. Unlike most other directories, it does not provide persistent storage for arbitrary files.Rather, it's a way to look at the systems's devices - their states and configurations. These files go away between boots and are dynamically generated by your system at startup. It is normal to be denied permission to write new files or directories there, even as root. You can detect these filesystems by viewing the mount type:
devpts
,proc
,sysfs
,binfmt_misc
, andfusectl
are all dynamically generated filesystems that reflect internal system information, and aren't for normal filesystem use. You will likely get permission denied errors even as root or other issues if you try to use these as a normal filesystem.tmpfs
is a temporary filesystem which resides within RAM - You can write to here and use it like a normal filesystem, but anything saved here will be erased as soon as the computer shuts down. Copy your files elsewhere if you want to save them.ext4
is an actual filesystem on a device somewhere. Data saved here will be preserved like you would expect on a harddisk. There are many filesystems, but the key note is how this line has/dev/md2
instead ofnone
:none
means that there is no device backing the filesystem - it doesn't really exist, and is entirely virtual. If a mount point has an actual device (like/dev/sda1
or/dev/md1
), then that means the contents actually exist on a device somewhere.Would you be able to put your edited files in another directory? Or do you specifically mean to edit the configuration of a device?