An open community 
of Macintosh users,
for Macintosh users.

FineTunedMac Dashboard widget now available! Download Here

Previous Thread
Next Thread
Print Thread
vsdbutil broken on server?
#10046 05/21/10 08:40 PM
Joined: Aug 2009
OP Offline

Joined: Aug 2009
OK long shot asking here but here goes.

One of my many scripts here uses vsdbutil to make sure owners are enabled on volumes before rsyncing. To do this it does a vsdbutil -c to check for owners enabled. If not, it uses vsdbutil -a to adopt them. (and then -c to check for success)

Problem. As of 10.6, apparently with server only, vsdbutil -c doesn't work. It says it can't find a database on that volume. The -a is working, it's just that the script thinks that all the volumes are disowned.

Just me? Workaround? tough luck?

apple:~ virtual1 $ vsdbutil -c /Volumes/Macintosh\ HD
No entry found for '/Volumes/Macintosh HD'.
apple:~ virtual1 $ echo $?
1

(this is the boot volume, obviously owners are enabled)

apple:~ virtual1 $ sudo vsdbutil -a /Volumes/Macintosh\ HD
Password:
apple:~ virtual1 $ echo $?
0

apple:~ virtual1 $ vsdbutil -c /Volumes/Macintosh\ HD
No entry found for '/Volumes/Macintosh HD'.

*sigh*

(affects all volumes, not just boot)

It's not having problems with the path. That produces different results

apple:~ virtual1 $ vsdbutil -c /Volumes/Macintosh\ HD123
vsdbutil: Couldn't get volume information for '/Volumes/Macintosh HD123': No such file or directory
vsdbutil: couldn't read volume UUID on '/Volumes/Macintosh HD123': No such file or directory



I work for the Department of Redundancy Department
Re: vsdbutil broken on server?
Virtual1 #10048 05/21/10 10:03 PM
Joined: Aug 2009
Likes: 16
Moderator
Online
Moderator

Joined: Aug 2009
Likes: 16
Running OS X 10.6.3, I get exactly the same results you are seeing. According the the BSD System Manager's Manual page the vsdbutil command is deprecated so I guess it is not too surprising to find inconsistencies in its functioning. After spending a good half hour browsing through the man pages with Bwana I don't know what to suggest as a replacement for the check status option. confused


If we knew what it was we were doing, it wouldn't be called research, would it?

— Albert Einstein
Re: vsdbutil broken on server?
joemikeb #10052 05/22/10 12:37 AM
Joined: Aug 2009
OP Offline

Joined: Aug 2009
The only other thing I can think of is possibly in diskutil, where man diskutil provides:

SEE ALSO
authopen(1), hdid(8), hdiutil(1), ufs.util(8), msdos.util(8), hfs.util(8), drutil(1), diskarbitrationd(8), mount(8), umount(8), newfs(8), vsdbutil(8),
fsck(8)

So apparently diskutil thinks you can continue using it. Kinda silly to depreciate it and not provide a replacement, eh? Where are you seeing it depreciated? Weird that it only affects server. (your tests were on server as well?)


I work for the Department of Redundancy Department
Re: vsdbutil broken on server?
Virtual1 #10055 05/22/10 02:32 AM
Joined: Sep 2009
Offline

Joined: Sep 2009
Can't speak for Server, but my Client is okay. [new 2010 MBP]

First check your database file for bad entries:

cat -ntv /var/db/volinfo.database

They should be clean (no weird chars), and on separate lines... like so:
Code:
     1	30544AFFA98BCA84: 00000001
     2	C714E6407D636815: 00000001
     3	8AAFC4A86301C774: 00000001
     4	0C2BEA1485DABC1C: 00000001
     5	A4E43C3F9C4B6CDC: 00000001


There was some weirdness back in Tiger (according to Shirt Pocket), which made newlines get lost and end up looking like this:
Code:
     1	30544AFFA98BCA84: 00000001
     2	C714E6407D636815: 00000001
     3	8AAFC4A86301C774: 000000010C2BEA1485DABC1C: 00000001
     4	A4E43C3F9C4B6CDC: 00000001

Also, i know sudo isn't needed for -c, but might it make any difference in your case?

--

So i wonder if the binary is different?
Here is my working 10.6.3 client:

type -a vsdbutil
vsdbutil is /usr/sbin/vsdbutil

md5 -q /usr/sbin/vsdbutil
87e5ecb867082ee04469ea8a9b865ca4

ls -l /usr/sbin/vsdbutil
-r-xr-xr-x 1 root wheel 76528 Feb 11 17:05 /usr/sbin/vsdbutil

Are your results different?

For something that's "deprecated", Feb 2010 seems like a pretty recent update.

Re: vsdbutil broken on server?
Virtual1 #10056 05/22/10 02:58 AM
Joined: Sep 2009
Offline

Joined: Sep 2009
Originally Posted By: Virtual1
The only other thing I can think of is possibly in diskutil, where man diskutil provides:

SEE ALSO
authopen(1), hdid(8), hdiutil(1), ufs.util(8), msdos.util(8), hfs.util(8), drutil(1), diskarbitrationd(8), mount(8), umount(8), newfs(8), vsdbutil(8),
fsck(8)

So apparently diskutil thinks you can continue using it. Kinda silly to depreciate it and not provide a replacement, eh? Where are you seeing it depreciated? Weird that it only affects server. (your tests were on server as well?)

Well, if -c is really busted (and/or vsdbutil is deprecated), then maybe:

Code:
for v in /Volumes/*
do
	if [[ $(diskutil info "$v" |
	   awk '/Owners:/ {print $2}') != Enabled ]]
	then
		diskutil enableOwnership "$v"
	fi
done

Or, heck... why even test at all? Just:

for v in /Volumes/*; do diskutil enableOwnership "$v"; done

[i'd expect diskutil to be smart enough not to repeat entries already in the db]

Re: vsdbutil broken on server?
Hal Itosis #10066 05/22/10 04:18 PM
Joined: Aug 2009
OP Offline

Joined: Aug 2009
Code:
Last login: Fri May 21 20:12:06 on ttys000

Welcome to Virtual1's MacBook Pro!

apple:~ virtual1 $ vsdbutil -c /Volumes/OWC/
No entry found for '/Volumes/OWC/'.
apple:~ virtual1 $ cat -ntv /var/db/volinfo.database
     1	
     2	D7365339BB07C1C3: 00000001
     3	EB0C229CE388595C: 00000001
     4	54DCC8B44C0DB324: 00000001
     5	9BA5C3AAFE8A27D6: 00000001
     6	12DCDAF5C34A30E2: 00000001
     7	60047F2D189CAC43: 00000001
     8	D7365339BB07C1C3: 00000001
     9	EB0C229CE388595C: 00000001
    10	54DCC8B44C0DB324: 00000001
    11	9BA5C3AAFE8A27D6: 00000001
    12	12DCDAF5C34A30E2: 00000001
    13	60047F2D189CAC43: 00000001
    14	D7365339BB07C1C3: 00000001
    15	EB0C229CE388595C: 00000001
    16	54DCC8B44C0DB324: 00000001
    17	9BA5C3AAFE8A27D6: 00000001
    18	12DCDAF5C34A30E2: 00000001
    19	60047F2D189CAC43: 00000001
    20	D7365339BB07C1C3: 00000001
    21	EB0C229CE388595C: 00000001
    22	54DCC8B44C0DB324: 00000001
    23	9BA5C3AAFE8A27D6: 00000001
    24	12DCDAF5C34A30E2: 00000001
    25	60047F2D189CAC43: 00000001
    26	D7365339BB07C1C3: 00000001
    27	54DCC8B44C0DB324: 00000001
    28	D7365339BB07C1C3: 00000001
    29	EB0C229CE388595C: 00000001
    30	54DCC8B44C0DB324: 00000001
    31	9BA5C3AAFE8A27D6: 00000001
    32	12DCDAF5C34A30E2: 00000001
    33	60047F2D189CAC43: 00000001
    34	24791A06C63849CD: 00000001
    35	597C80F1741A8613: 00000001
    36	DBEF4E0DBFB8E421: 00000001
    37	B4581ABD5AC03CD0: 00000001
    38	12DCDAF5C34A30E2: 00000001
    39	7B88AAA470706D15: 00000001
    40	C9ECD09F44204862: 00000001
    41	C711D9F122E2472B: 00000001
    42	24791A06C63849CD: 00000001
    43	597C80F1741A8613: 00000001
    44	DBEF4E0DBFB8E421: 00000001
    45	B4581ABD5AC03CD0: 00000001
    46	12DCDAF5C34A30E2: 00000001
    47	7B88AAA470706D15: 00000001
    48	1FB158B2AC1368F9: 00000001
    49	C9ECD09F44204862: 00000001
    50	1634B3B166301447: 00000001
    51	D7365339BB07C1C3: 00000001
    52	1AACE26892A59899: 00000001
    53	54DCC8B44C0DB324: 00000001
    54	B3C8E94E18C64249: 00000001
    55	24791A06C63849CD: 00000001
    56	7603641097B3F903: 00000001
    57	DBEF4E0DBFB8E421: 00000001
    58	7C666BE6D2A086EE: 00000001
    59	12DCDAF5C34A30E2: 00000001
    60	E0B9CCF9652E86B7: 00000001
    61	C9ECD09F44204862: 00000001
    62	9259D008E1B46D6E: 00000001
    63	54DCC8B44C0DB324: 00000001
    64	2A61EDA495371D9D: 00000001
    65	24791A06C63849CD: 00000001
    66	27EA72D16D790B90: 00000001
    67	DBEF4E0DBFB8E421: 00000001
    68	351E77CD555E6601: 00000001
    69	12DCDAF5C34A30E2: 00000001
    70	01C95760E26B249A: 00000001
apple:~ virtual1 $ type -a vsdbutil
vsdbutil is /usr/sbin/vsdbutil
apple:~ virtual1 $ md5 -q /usr/sbin/vsdbutil
6a1a6785606dbe0ac6981f4667a182af
apple:~ virtual1 $ ls -l /usr/sbin/vsdbutil
-r-xr-xr-x  1 root  wheel  76528 Feb 10 23:41 /usr/sbin/vsdbutil
apple:~ virtual1 $ diskutil enableownership /Volumes/OWC
You must be root for this command
apple:~ virtual1 $ sudo diskutil enableownership /Volumes/OWC
Password:
Filesystem user/group ownership enabled
apple:~ virtual1 $ sudo diskutil disableownership /Volumes/OWC
Filesystem user/group ownership disabled
apple:~ virtual1 $ vsdbutil -c /Volumes/OWC/
No entry found for '/Volumes/OWC/'.
apple:~ virtual1 $ vsdbutil -a /Volumes/OWC/
###
### You must be root to perform this operation.
###
apple:~ virtual1 $ sudo vsdbutil -a /Volumes/OWC/
apple:~ virtual1 $ 


Yes I thought I had looked in diskutil for the commands but apparently overlooked them. Interesting my vsdbutil crc is different than yours. I wonder if apple bundled a bad build with server?

Code:
apple:~ virtual1 $ md5 -q /Volumes/Service\ Snow/usr/sbin/vsdbutil
6a1a6785606dbe0ac6981f4667a182af


or yours is different wink 10.6.3 here. Interesting, I didn't know there was an md5 tool. I use "openssl md5" usually.

I can just use diskutil I guess.

Checking another one I know works (client):

Service-Right:~ root # md5 -q /usr/sbin/vsdbutil
6a1a6785606dbe0ac6981f4667a182af

Since the checksums are the same in server and client, it's not the binary. It works on all the clients, and does NOT work on hard drives attached to server (so no db issue?), and this is the only server I have to test so maybe this server install is broken? Anyone else with SL server? Either that or a framework in server is broken?


I work for the Department of Redundancy Department
Re: vsdbutil broken on server?
Virtual1 #10069 05/22/10 11:00 PM
Joined: Sep 2009
Offline

Joined: Sep 2009
Originally Posted By: Virtual1
Interesting my vsdbutil crc is different than yours. I wonder if apple bundled a bad build with server?

apple:~ virtual1 $ md5 -q /Volumes/Service\ Snow/usr/sbin/vsdbutil
6a1a6785606dbe0ac6981f4667a182af

or yours is different wink 10.6.3 here.

Mine is from a very recent Macbook Pro (core i7).
sw_vers
ProductName: Mac OS X
ProductVersion: 10.6.3
BuildVersion: 10D2094


Those two vsdbutil binaries seem nearly identical, but mine is almost a day newer:

-r-xr-xr-x 1 root wheel 76528 Feb 10 23:41 /usr/sbin/vsdbutil <--- yours
-r-xr-xr-x 1 root wheel 76528 Feb 11 17:05 /usr/sbin/vsdbutil <--- mine



Originally Posted By: Virtual1
Since the checksums are the same in server and client, it's not the binary. It works on all the clients, and does NOT work on hard drives attached to server (so no db issue?), and this is the only server I have to test so maybe this server install is broken? Anyone else with SL server? Either that or a framework in server is broken?

Okay yes, that suggests the binary can be ruled out then maybe (though our differing checksums remain a curiosity).

I'm not so sure your db there is in perfect shape though. Note the empty line #1 :
Code:
apple:~ virtual1 $ cat -ntv /var/db/volinfo.database
     1	
     2	D7365339BB07C1C3: 00000001
     3	EB0C229CE388595C: 00000001
     4	54DCC8B44C0DB324: 00000001
 

No biggie perhaps... i just never seen line #1 blank like that before.

It may be worth it to erase (rm) that /var/db/volinfo.database file completely, and then fully reinitialize it via:

sudo vsdbutil -i

[if that fails... we gain another "clue" wink and you can always resort to the diskutil method to rebuild it.]

Last edited by Hal Itosis; 05/22/10 11:10 PM.
Re: vsdbutil broken on server?
Hal Itosis #10070 05/22/10 11:30 PM
Joined: Aug 2009
OP Offline

Joined: Aug 2009
NICE CATCH, Hal

apple:/var/db root # pico volinfo.database
apple:/var/db root # vsdbutil -c /Volumes/OWC
Permissions on '/Volumes/OWC' are enabled.
apple:/var/db root # vsdbutil -d /Volumes/OWC
apple:/var/db root # vsdbutil -c /Volumes/OWC
Permissions on '/Volumes/OWC' are disabled.
apple:/var/db root #

smile


Deleted the blank line at the top of the file. No doubt all the drives I access all the time increase the odds of that getting bugged. Heck, when I'm syncing a service drive, I have oh lets see... 27 volumes attached at a time... heh.


I work for the Department of Redundancy Department

Moderated by  alternaut, dkmarsh, joemikeb 

Link Copied to Clipboard
Powered by UBB.threads™ PHP Forum Software 7.7.4
(Release build 20200307)
Responsive Width:

PHP: 7.4.33 Page Time: 0.022s Queries: 30 (0.018s) Memory: 0.6191 MB (Peak: 0.7134 MB) Data Comp: Zlib Server Time: 2024-03-29 15:51:43 UTC
Valid HTML 5 and Valid CSS