Bug 153142 - [zfs] ls -l outputs `ls: ./.zfs: Operation not supported'
Summary: [zfs] ls -l outputs `ls: ./.zfs: Operation not supported'
Status: Closed DUPLICATE of bug 225793
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: 8.1-RELEASE
Hardware: Any Any
: Normal Affects Only Me
Assignee: Alan Somers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-12-14 07:10 UTC by Hiroshi Fujishima
Modified: 2018-02-14 17:10 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Hiroshi Fujishima 2010-12-14 07:10:11 UTC
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
Comment 1 Rebecca Cran freebsd_committer 2010-12-14 19:54:21 UTC
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
Comment 2 Jaakko Heinonen freebsd_committer 2011-01-14 09:00:50 UTC
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
Comment 3 Edward Tomasz Napierala freebsd_committer 2011-01-14 09:07:02 UTC
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?
Comment 4 Marcelo Araujo freebsd_committer 2012-04-16 04:53:31 UTC
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.
Comment 5 Marcelo Araujo freebsd_committer 2012-04-16 07:28:17 UTC
State Changed
From-To: open->closed

It was solved on PR number 150544.
Comment 6 Marcelo Araujo freebsd_committer 2012-08-19 07:59:21 UTC
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.

Comment 7 Marcelo Araujo freebsd_committer 2012-08-19 08:02:03 UTC
State Changed
From-To: feedback->open

- Put it back to the freebsd-fs pool. 


Comment 8 Marcelo Araujo freebsd_committer 2012-08-19 08:02:03 UTC
Responsible Changed
From-To: araujo->freebsd-fs

- Put it back to the freebsd-fs pool.
Comment 9 Pawel Jakub Dawidek freebsd_committer 2014-06-01 07:26:57 UTC
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?
Comment 10 Eitan Adler freebsd_committer freebsd_triage 2017-12-31 07:58:55 UTC
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
Comment 11 Alan Somers freebsd_committer 2018-02-14 17:10:20 UTC
Fixed for real by r329265 .

*** This bug has been marked as a duplicate of bug 225793 ***