docs/95139: FAQ to move filesystem to new disk fails: incorrect permissions

Doug Hawkins illusion65 at gmail.com
Fri Mar 31 03:20:17 UTC 2006


>Number:         95139
>Category:       docs
>Synopsis:       FAQ to move filesystem to new disk fails: incorrect permissions
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-doc
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          doc-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Mar 31 03:20:16 GMT 2006
>Closed-Date:
>Last-Modified:
>Originator:     Doug Hawkins
>Release:        FreeBSD 6.0-RELEASE
>Organization:
N/A
>Environment:
FreeBSD soho.localhost.net 6.0-RELEASE FreeBSD 6.0-RELEASE #0: Fri Mar 31 14:40:20 NZST 2006
doug at soho.localhost.net:/usr/src/sys/i386/compile/GBDEKRNL  i386
NOTE: I was using GENERIC from the 6.0 ISO's when this problem occurred
>Description:
I needed to move my /var, and /usr partitions to a different slice, so I followed the directions on:

<http://www.freebsd.org/doc/faq/disks.html#NEW-HUGE-DISK>

dump 0af - /var | restore xf -

but that did not properly restore the file permissions.

I later used:

dump 0f - /var | restore rf -

note the 'r' option instead of the 'x' for restore.

Even though the documentation states that 'restore x' will attempt to restore file permissions, it did not work for my system.  This could be very frustrating for someone who doesn't notice until later that many system services do not run properly (e.g.: MySQL cannot run because it's /var/db/mysql directory is no longer accessible {700 root:wheel} instead of {755 mysql:mysql}).
>How-To-Repeat:
Follow directions in FAQ to create a newfs & copy a partition, then compare the permission, owner, group for destination files & directories.
>Fix:
use 'restore r' instead of 'restore x'
>Release-Note:
>Audit-Trail:
>Unformatted:



More information about the freebsd-doc mailing list