On Thu, 5 Dec 2002, kai ouyang wrote:

> Hi, everybody,
> >From Robert N M Watson
> >(1) UFS_ACL isn't enabled
> Yes, I am sure that in my kernel config:
> options UFS_ACL
> options UFS_EXTATTR

Ok, looks good.

> >(2) Extended attributes aren't available on the file system (shouldn't
> >    happen for UFS2, but might happen for UFS1 if you don't have
> >    UFS_EXTATTR and appropriate configuration of EAs) 
> I do as the "README.alcs"
> mkdir -p /usr/.attribute/system
> cd /.attribute/system
> extattrctl initattr -p /usr/ 388 posix1e.acl_access
> extattrctl initattr -p /usr/ 388 posix1e.acl_default

Followed by a reboot, right?

> >(3) The file system isn't mounted with the ACL option: either -o acls (or
> >    acls in the fstab file), or more reliably, setting the "tunefs -a
> >    enable" flag in the file system configuration.
> >For better or for worse, POSIX.1e defines that getfacl() will print the
> >current file permissions as an ACL if ACLs aren't available on the file
> >system.  As such, you're probably just seeing the results of stat()
> >printed in an ACL form.
> I use UFS1. In DP1, the ACL works nice. But in DP2, I have never succeeded.
> in DP1, there is no need to add the 'acls' to 'fstab'. Anyway, I also add 
> the 'acls' flag to 'fstab', but it fails, too.
> The system always say:
> Current#cd /usr/
> Current#setfacl -m u:oyk:r src
> setfacl: acl_get_file() failed: Operation not supported

If you run mount, does it show the "acls" flag for /usr?  I generally
recommend that the tunefs flag be used to start ACLs on a file system
rather than the fstab flag, since that will prevent races and issues with
re-mounting for /.  Try the following:

tunefs -a enable /dev/{deviceof/usr}

then unmount and remount the file system (probably by rebooting).  Here's
the procedure I use to test ACLs locally when I don't want to mess with a
live file system:

alsvid# mdconfig -a -t malloc -s4m
alsvid# newfs /dev/md0
/dev/md0: 4.0MB (8192 sectors) block size 16384, fragment size 2048
        using 4 cylinder groups of 1.02MB, 65 blks, 256 inodes.
super-block backups (for fsck -b #) at:
 32, 2112, 4192, 6272
alsvid# mount /dev/md0 /mnt
alsvid# cd /mnt
alsvid# mkdir -p .attribute/system
alsvid# cd .attribute/system/
alsvid# extattrctl initattr -p . 388 posix1e.acl_access 
alsvid# extattrctl initattr -p . 388 posix1e.acl_default
alsvid# cd /mnt
alsvid# setfacl -m u:robert:r .
setfacl: acl_get_file() failed: Operation not supported
alsvid# cd /
alsvid# umount /mnt
alsvid# tunefs -a enable /dev/md0
tunefs: ACLs set
alsvid# mount /dev/md0 /mnt
alsvid# mount
/dev/ad0s1a on / (ufs, NFS exported, local, soft-updates)
devfs on /dev (devfs, local, multilabel)
/dev/md0 on /mnt (ufs, local, acls)
alsvid# setfacl -m u:robert:r .
alsvid# ls -la
total 5
drwxr-xr-x+  3 root  wheel   512 Dec  5 10:40 .
drwxr-xr-x  20 root  wheel  1024 Nov 29 16:00 ..
drwxr-xr-x   3 root  wheel   512 Dec  5 10:40 .attribute
alsvid# getfacl .

Try using tunefs and see how things go.  BTW, we're generally recommending
the use of UFS2 with ACLs because the extended attribute support is
substantially faster and more reliable.

It looks like there may be a problem with the processing of the "acls" 
flag as an argument of the mount command.  I'll investigate locally and
see if that's the cause -- if so, that would result in what you're seeing. 

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED]      Network Associates Laboratories

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to