changing ownership resets permissions to 0000

[devsk]

Not sure why would this happen:

/rpool/test 
# l
total 6
drwxr-xr-x 2 root root      3 Feb 22 20:46 ./
drwxr-xr-x 3 root root   4096 Feb 22 20:44 ../
-rw-r--r-- 1 root root 171299 Feb 22 20:46 dead.letter

/rpool/test 
# chown devsk .

/rpool/test 
# l
total 84
d--------- 2 devsk root      3 Feb 22 20:46 ./
drwxr-xr-x 3 root    root   4096 Feb 22 20:44 ../
-rw-r--r-- 1 root    root 171299 Feb 22 20:46 dead.letter

Changing the perms works fine.

[behlendorf]

That's a bit odd... what happens when you try something like that on say ext4?

[devsk]

The sane thing...:-) I see perms staying the same and owner changing to devsk.

[fajarnugraha]

Some more info on this: the error only happens when the directory is the mountpoint of zfs dataset (e.g. in devsk's example, rpool/test should be a zfs dataset). It does not happen when the directory is a normal directory on zfs filesystem, and it does not happen when the directory is the mountpoint of ext4 filesystem.

[mjonuschat]

I can confirm this on Ubuntu 10.04 with the following code:

Kernel: 2.6.32-31-server
SPL: git commit d837ae3
ZFS: git commit a1cc0b3

[kohlschuetter]

Still having the same problems with latest pull from master.

[behlendorf]

Reopening issue, this may not be fixed after all.

[kohlschuetter]

Seems that the problem occurs when creating a zfs filesystem using "zfs create" (even nested ones), but not when creating simple directories (using mkdir).

I have the impression that somehow the mode of the fs mount point's inode is not persisted in the first place.

As a preliminary workaround, "zfs create" could perform an extra "chmod" at the end of creating the fs. However, this would hide the actual cause.

[behlendorf]

Note this fix will only resolve the issue for new zfs datasets.