vsdbutil broken on server?
|
|
OP
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?
|
Joined: Aug 2009
Likes: 16
Moderator
|
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.
If we knew what it was we were doing, it wouldn't be called research, would it?
— Albert Einstein
|
|
Re: vsdbutil broken on server?
|
|
OP
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?
|
|
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:
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:
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?
|
|
Joined: Sep 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?) Well, if -c is really busted (and/or vsdbutil is deprecated), then maybe:
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?
|
|
OP
Joined: Aug 2009
|
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?
apple:~ virtual1 $ md5 -q /Volumes/Service\ Snow/usr/sbin/vsdbutil
6a1a6785606dbe0ac6981f4667a182af
or yours is different 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?
|
|
Joined: Sep 2009
|
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 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
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 :
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" 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?
|
|
OP
Joined: Aug 2009
|
NICE CATCH, Halapple:/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 # 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
|
|
|
|