Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm working with zfs-fuse as a way to provide filesystem compression on existing CentOS 5 servers. I'm dealing with a highly-compressible dataset (80%), so zfs-fuse comes in handy. I'm encountering file permission problems with the storage pools.

It appears that zfs-fuse is ignoring or only partially recognizing file permissions for non-owners.

Assuming a zfs-fuse filesystem mounted at: /app/november comprised of files with permissions of 666 (-rw-rw-rw-) and owner "jack", I can read files and delete them as user "jill". However, I cannot write to those files or save them. Basically, everything is read-only if I'm not the owner of the files.

[jill@Vail /app/november]$ whoami

[jill@Vail /app/november]$ ls -l testfile
-rw-rw-rw- 1 jack jack 27 Dec 18 12:12 testfile

[jill@Vail /app/november]$ touch testfile
touch: setting times of `testfile': Operation not permitted

[jill@Vail /app/november]$ rm testfile 
[jill@Vail /app/november]$ touch testfile
[jill@Vail /app/november]$ ls -l
total 1
-rw-rw-rw- 1 jill jill 0 Dec 18 13:57 testfile

Any ideas? Is there a fix for this? I think this is a Fuse issue, as I've seen similar issues elsewhere for this and other Fuse filesystems...

The zfs-fuse package was downloaded from the EPEL repository.
rpm info...

Edit - The mount output is as follows, showing zpool mounts and the Fuse info.

[root@Vail ~]# mount
/dev/cciss/c0d0p2 on / type ext3 (rw,noatime)
/dev/cciss/c0d0p9 on /app type xfs (rw,noatime,logbufs=8,logbsize=256k,nobarrier)
/dev/cciss/c0d0p8 on /tmp type ext3 (rw,noatime)
/dev/cciss/c0d0p7 on /var type ext3 (rw,noatime)
/dev/cciss/c0d0p3 on /usr type ext3 (rw,noatime)
/dev/cciss/c0d0p1 on /boot type ext3 (rw)
kstat on /zfs-kstat type fuse (rw,nosuid,nodev,allow_other)
vol1 on /vol1 type fuse (rw,allow_other,default_permissions)
vol1/november on /app/november type fuse (rw,allow_other,default_permissions)
vol1/december on /app/december type fuse (rw,allow_other,default_permissions)
share|improve this question
can you provide mount output? – Giovanni Toraldo Dec 19 '11 at 15:50
Revised with mount information. – ewwhite Dec 19 '11 at 16:21
can you give us the permissions of /app/november after it's been mounted? ls -la /app/november thanks. – Jayen Dec 25 '11 at 9:39
ls -ld /app/november/ returns drwxrwxrwx 2 jack jack 3 Dec 18 13:57 /app/november/ – ewwhite Dec 25 '11 at 11:42
up vote 0 down vote accepted

Please try upgrading to a more recent fuse version. Fuse 2.8 introduced a new function (FUSE_VFS_HAS_DEFAULT_PERM) which if IIRC has to do with group permissions

Don't know the specifics any more, but I think the group perms were to slow to implement properly before that time.

share|improve this answer
I tried updating fuse on the system. The userspace and tools updated, but the fuse.ko kernel module is part of the RHEL 5 kernel. It can't be updated easily. Do I need to patch the kernel source? – ewwhite Dec 28 '11 at 12:54

IMHO rights for remove file are given by rights for directory (remove is operation on the directory), not the file... And what will doing:

echo "1" > testfile

as a jill, when testfile is owned by jack?

share|improve this answer
echo "1" > testfile -bash: testfile: Operation not permitted – ewwhite Dec 21 '11 at 12:13
Hmmm... Then it seems to be a bug... :-(. – Jan Marek Dec 21 '11 at 12:22

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.