1. filesystem is zfs 2. snapdir property is visible 3. top directory of file system has .a file. with above condition, ls -l outputs `ls: ./.zfs: Operation not supported' How-To-Repeat: backup8y# zfs create -o mountpoint=/test -o snapdir=visible tank/test backup8y# ls -l /test total 0 dr-xr-xr-x 3 root wheel 3 Dec 14 15:46 .zfs backup8y# touch /test/.a backup8y# ls -l /test total 1 -rw-r--r-- 1 root wheel 0 Dec 14 15:46 .a ls: /test/.zfs: Operation not supported dr-xr-xr-x 3 root wheel 3 Dec 14 15:46 .zfs
On Tue, 14 Dec 2010 07:02:32 GMT Hiroshi Fujishima <hirobo@tonteki.org> wrote: > with above condition, ls -l outputs `ls: ./.zfs: Operation not > supported' I can confirm that this occurs on HEAD too: the .zfs directory can't be listed but directories under it can. -- Bruce Cran
Hi, On 2010-12-14, Hiroshi Fujishima wrote: > >Description: > 1. filesystem is zfs > 2. snapdir property is visible > 3. top directory of file system has .a file. > > with above condition, ls -l outputs `ls: ./.zfs: Operation not supported' > > >How-To-Repeat: > backup8y# zfs create -o mountpoint=/test -o snapdir=visible tank/test > backup8y# ls -l /test > total 0 > dr-xr-xr-x 3 root wheel 3 Dec 14 15:46 .zfs > backup8y# touch /test/.a > backup8y# ls -l /test > total 1 > -rw-r--r-- 1 root wheel 0 Dec 14 15:46 .a > ls: /test/.zfs: Operation not supported > dr-xr-xr-x 3 root wheel 3 Dec 14 15:46 .zfs ls(1) detects from the first file in the listing if the file system supports ACLs and assumes that all files on the same file system support ACLs. The ".zfs" directory is special and doesn't support ACLs. Thus ls(1) prints an error message for acl_get_link_np(3) failure. Also, if the ".zfs" directory is the first entry of a listing, ls(1) assumes that files on the same file system don't have ACLs and doesn't print '+' after mode. -- Jaakko
Wiadomo=B6=E6 napisana przez Jaakko Heinonen w dniu 2011-01-14, o godz. = 10:00: > On 2010-12-14, Hiroshi Fujishima wrote: >>> Description: >> 1. filesystem is zfs >> 2. snapdir property is visible >> 3. top directory of file system has .a file. >>=20 >> with above condition, ls -l outputs `ls: ./.zfs: Operation not = supported' >>=20 >>> How-To-Repeat: >> backup8y# zfs create -o mountpoint=3D/test -o snapdir=3Dvisible = tank/test >> backup8y# ls -l /test >> total 0 >> dr-xr-xr-x 3 root wheel 3 Dec 14 15:46 .zfs >> backup8y# touch /test/.a >> backup8y# ls -l /test >> total 1 >> -rw-r--r-- 1 root wheel 0 Dec 14 15:46 .a >> ls: /test/.zfs: Operation not supported >> dr-xr-xr-x 3 root wheel 3 Dec 14 15:46 .zfs >=20 > ls(1) detects from the first file in the listing if the file system > supports ACLs and assumes that all files on the same file system = support > ACLs. The ".zfs" directory is special and doesn't support ACLs. Thus > ls(1) prints an error message for acl_get_link_np(3) failure. >=20 > Also, if the ".zfs" directory is the first entry of a listing, ls(1) > assumes that files on the same file system don't have ACLs and doesn't > print '+' after mode. I guess the easiest way to fix this would be to add "dummy" ACL support for ".zfs" directory - that is, to zfsctl_ops_root[], if I'm reading = this correctly. -- If you cut off my head, what would I say? Me and my head, or me and my = body?
Responsible Changed From-To: freebsd-bugs->araujo I'm performing some tests using ZFS + NFS and I found the same issue on FreeBSD 8, but not on FreeBSD-10, I'm gonna performe more debugs to check how solve it on version 8.
State Changed From-To: open->closed It was solved on PR number 150544.
State Changed From-To: open->feedback Hi Pjd and Hirobo, I got two different problems related with almost the same issue, but all of my problems were related when I tried to access .zfs via NFS, even with a simple 'ls -a'. The patch bellow fix one part of the issue. And also I have another patch that implement a dummy NFSv4 ACL for .zfs pseudo-directory, but as I spoke with PJD, maybe I'm not able to share this patch. Those two patchs mentioned above, right now I'm using them on FreeBSD-9.0-RELEASE, and I can't reproduce the problem, maybe the dummy NFSv4 ACL does more than I thought, and close this PR was my mistake. The patch below is related when perform the command 'ls -a /mnt/.zfs/' via a shared NFS pool. I made tests using Linux, Mac and FreeBSD, in all of them it works and does not crash anymore. However with the FreeBSD-CURRENT it does not happen, maybe because of the NFSv4. So, sorry to close the PR.
State Changed From-To: feedback->open - Put it back to the freebsd-fs pool.
Responsible Changed From-To: araujo->freebsd-fs - Put it back to the freebsd-fs pool.
State Changed From-To: closed->open How exactly was it fixed? Can you point me at revision that was suppose to fix it? You are not able to reproduce it after the fix went in?
For bugs matching the following criteria: Status: In Progress Changed: (is less than) 2014-06-01 Reset to default assignee and clear in-progress tags. Mail being skipped
Fixed for real by r329265 . *** This bug has been marked as a duplicate of bug 225793 ***