Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 11 Aug 2016 10:04:11 +0200
From:      "O. Hartmann" <ohartman@zedat.fu-berlin.de>
To:        freebsd-current <freebsd-current@freebsd.org>
Subject:   CURRENT: NFSv4/autofs and ZFS weirdness: permission denied
Message-ID:  <20160811100411.2d30546f@freyja.zeit4.iv.bundesimmobilien.de>

next in thread | raw e-mail | index | archive | help
Both server and clients are running most recent 12-CURRENT. The server is
exporting a ZFS volume via NFSv4. I recently copied that volume from another
volume via zfs send/receive from one vilume on the same server to another
volume, created on another sorage device.

The specific volume worked before in the environment I use. It is exported via
NFSv4 by the server with -maproot=www:www and read/writeable by only one
specific host and imported via NFSv4 autofs by that specific host. The purpose
is to synchronize via "rsync -rv" packages created via poudriere on a very
fast smaller machine to the fileserver. The owner of the volume's folder
hierarchy is "www:www" with unaltered, proper access rights.

The last time the sync worked was July, 20th. Now, since a couple of days or
weeks, I get an error: permission denied. root is the user trying to rsync
from the poudriere creator host to write the packages folder hierarchy and
packages to the autofs volume, but the procedure fails.

I have no clue what changed. I checked whether the ZFS volume is locked in
any way after it has been sent/received, but it isn't. It looks like an
ordinary volume and locally (from the perspective of the fileserver) creation
and deletion of files is possible.

What do I miss here?

The fact that this procedure worked with 11-CURRENT and 11-ALPHA weeks ago as
it is, makes me suspect a bug or fundamentaly change in the bahviour or - there
is a hidden lock when zfs send/receive is used I didn't realizes to relief.

Thanks in advance for help and considerations,

Oliver



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160811100411.2d30546f>