I am trying to get write acces to a windows vfat partition. During this I changed permissions with chmod. Seemingly chmod did the job but in reality it did not. This is feigning functionality! See this: katzes:~# chmod 0777 /windowsC katzes:~# ls -l / total 154 drwxr-xr-x 2 root root 4096 Feb 24 14:58 bin drwxr-xr-x 3 root root 4096 Jan 14 11:26 boot .. .. .. lrwxrwxrwx 1 root root 24 Jan 11 11:37 vmlinuz.old -> boot/vmlinuz-2.6.8-1-386 drwxr--r-- 38 root root 8192 Jan 1 1970 windowsC As you can see chmod accepted the order to change permissions, but did nothing. BTW: Could you please encourage the debian team to replace this horrible bug report program.
Error is worse than I thoght:
chmod is not only suppressing an error message, it is even reporting a
success!
katzes:/# stat windows
File: `windows'
Size: 4096 Blocks: 8 IO Block: 4096 directory
Device: 2141h/8513d Inode: 1 Links: 6
Access: (0755/drwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/
root)
Access: 1970-01-01 01:00:00.000000000 +0100
Modify: 1970-01-01 01:00:00.000000000 +0100
Change: 2005-06-30 23:44:19.169147744 +0200
katzes:/# chmod 777 windows -v
mode of `windows' changed to 0777 (rwxrwxrwx)
katzes:/# stat windows
File: `windows'
Size: 4096 Blocks: 8 IO Block: 4096 directory
Device: 2141h/8513d Inode: 1 Links: 6
Device: 2141h/8513d Inode: 1 Links: 6
Access: (0755/drwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/
root)
Access: 1970-01-01 01:00:00.000000000 +0100
Modify: 1970-01-01 01:00:00.000000000 +0100
Change: 2005-06-30 23:51:20.426106952 +0200
As you can see: After chmod has reported having changed the rights to
rwxrwxrwx they are still rwxr-xr-x.
A program not doing what it is supposed to do is bad enough but a
program lying to the user is even worse!
Jürgen Katins wrote:
Inode one seems really strange to me. That would not be a normal
filesystem. What type of filesystem is this? You can use 'df -T' to
show this information. Looks wrong to me.
What does an strace of the run show?
strace -e chmod chmod -v 0777 windows
If it shows something like this, then the kernel chmod(2) call
reported success and the problem is in your kernel.
chmod("testfile", 0777) = 0
I think the problem is not chmod but instead that you have a problem
with the filesystem upon which it is being run. If the filesystem is
reporting erroneous information then the problem is there.
The strace information should show the kernel system call return code
and clarify the location of problem.
Bob
severity 296836 normal tags 296836 wontfix stop This is how chmod works when operating on vfat filesystems (which don't have real UNIX permission bits). jdthood@turmeric:/mnt/hda2/tmp$ ls -l aaa # on vfat filesystem -rwxr-xr-x 1 root root 0 2004-12-18 09:17 aaa jdthood@turmeric:/mnt/hda2/tmp$ sudo chmod ugo+w aaa && echo Success Success jdthood@turmeric:/mnt/hda2/tmp$ ls -l aaa -rwxr-xr-x 1 root root 0 2004-12-18 09:17 aaa jdthood@turmeric:/mnt/hda2/tmp$ cd /tmp # to ext3 filesystem jdthood@turmeric:/tmp$ touch aaa jdthood@turmeric:/tmp$ ls -l aaa -rw-r--r-- 1 jdthood jdthood 0 2005-10-14 12:02 aaa jdthood@turmeric:/tmp$ sudo chmod ugo+w aaa && echo Success Success jdthood@turmeric:/tmp$ ls -l aaa -rw-rw-rw- 1 jdthood jdthood 0 2005-10-14 12:02 aaa
hi
'man mount', regarding FAT mounts , explains the 'quiet' flag as follows:
quiet Turn on the quiet flag. Attempts to chown or chmod files do not
return errors, although they fail. Use with caution!
I gave it a try: it seems that 'chown' works as documented:
when 'quiet' is not set, indeed
# chown D /media/usbdisk/promemoria.pdf ; echo $?
chown: changing ownership of `/media/usbdisk/promemoria.pdf': Operation not permitted
1
But 'chmod' does never return an error on VFAT filesystem,
(in all the way that I tried it);
so maybe a small change in documentation may be useful; something as
quiet Turn on the quiet flag. Attempts to chown files do not
return errors, although they fail. Use with caution!
Beware that, in general, 'chmod' will not return errors on VFAT,
but will mostly fail to do what you expect it to do, due to limitations
in the filesystem.
a.
I confirm that the behavior of the function are not consistent. This problem have also chown. I have the same problem with my vfat windows permissions. But chmod and chown they have return code 0 and they not change anything even as root or user level. These commands must verify their executions and return 0 when something is wrong is not a good programming practice. $cat /ect/debian_version 9.6 $ strace -e chmod chmod -v 0777 sf_Java11Machine der Modus von 'sf_Java11Machine' wurde von 0770 (rwxrwx---) in 0777 (rwxrwxrwx) geändert +++ exited with 0 +++ $ ls -la insgesamt 15 drwxr-xr-x 5 root root 4096 Nov 26 23:53 . drwxr-xr-x 21 root root 4096 Nov 16 14:10 .. drwxr-xr-x 2 root root 4096 Nov 16 14:06 cdrom drwxrwx--- 1 root vboxsf 0 Nov 30 12:26 sf_Java11Machine dr-xr-xr-x 6 root root 2226 Nov 8 20:58 sr0 $ strace -e chown chown -v frank sf_Java11Machine der Eigentümer von 'sf_Java11Machine' wurde von root in frank geändert +++ exited with 0 +++ frank@antix1-java11:/media $ ls -la insgesamt 15 drwxr-xr-x 5 root root 4096 Nov 26 23:53 . drwxr-xr-x 21 root root 4096 Nov 16 14:10 .. drwxr-xr-x 2 root root 4096 Nov 16 14:06 cdrom drwxrwx--- 1 root vboxsf 0 Nov 30 12:26 sf_Java11Machine dr-xr-xr-x 6 root root 2226 Nov 8 20:58 sr0