{"id":6436,"date":"2017-09-28T10:44:22","date_gmt":"2017-09-28T00:44:22","guid":{"rendered":"http:\/\/nsrd.info\/blog\/?p=6436"},"modified":"2018-12-11T08:13:08","modified_gmt":"2018-12-10T22:13:08","slug":"basics-device-x-is-marked-as-suspect","status":"publish","type":"post","link":"https:\/\/nsrd.info\/blog\/2017\/09\/28\/basics-device-x-is-marked-as-suspect\/","title":{"rendered":"Basics – device `X’ is marked as suspect"},"content":{"rendered":"

So I got myself into a bit of a kerfuffle today when I was doing some reboots in my home lab. When one of my DDVE systems came back up and I attempted to re-mount the volume hosted on that Data Domain in NetWorker, I got an odd error:<\/p>\n

device `X’ is marked as suspect<\/p><\/blockquote>\n

Now, that’s odd, because NetWorker marks savesets<\/em> as suspect, not volumes.<\/p>\n

Trying it out on the command line still got me the same results:<\/p>\n

[root@orilla ~]# nsrmm -mv -f adamantium.turbamentis.int_BoostClone<\/strong>\n155485:nsrd: device `adamantium.turbamentis.int_BoostClone' is marked as suspect<\/pre>\n
Curiouser curiouser, I thought. I did briefly try to mark the volume as not suspect, but this didn’t make a difference, of course – since suspect<\/em> applies to savesets, not volumes:<\/p>\n
[root@orilla ~]# nsrmm -o notsuspect BoostClone.002<\/strong>\n6291:nsrmm: Volume is invalid with -o [not]suspect<\/pre>\n
I could see the volume was not<\/em> marked as scan needed, and even explicitly re-marking the volume as not requiring a scan didn’t change anything.<\/p>\n
Within NMC I’d been trying to mount the Boost volume under Devices > Devices. I viewed the properties of the relevant device and couldn’t see anything about the device being suspect, so I thought I’d pop into Devices > Data Domain Devices and view the device details there. Nothing different there, but when I attempted to mount the device from there, it instead told me the that the ‘ddboost’ user associated with the Data Domain didn’t have the rights<\/em> required to access the device.<\/p>\n
\"Insufficient<\/a><\/p>\n
That was my Ahah!<\/em> moment. To test my theory I tried to login as the ddboost user onto the Data Domain:<\/p>\n
[Thu Sep 28 10:15:15]\n[\u2022 ~ \u2022]\npmdg@rama \n$ ssh ddboost@adamantium<\/strong>\nEMC Data Domain Virtual Edition\nPassword: \nYou are required to change your password immediately (password aged)\nChanging password for ddboost.\n(current) UNIX password:<\/pre>\n
Eureka!<\/em><\/p>\n
\"Eureka!\"<\/a><\/p>\n
I knew I’d set up that particular Data Domain device in a hurry to do some testing, and I’d forgotten to disable password ageing.<\/em> Sure enough, when I logged into the Data Domain Management Console, under Administration > Access > Local Users, the ‘ddboost’ account was showing as locked<\/em>.<\/p>\n
Solution: edit the account properties for the ‘ddboost’ user and give it a 9999 day ageing policy.<\/p>\n
Huzzah! Now the volume would mount on the device.<\/p>\n
There’s a lesson here \u2013 in fact, a couple:<\/p>\n
    \n
  1. Being in a rush to do something and not doing it properly usually catches you later on.<\/li>\n
  2. Don’t stop at your first error message \u2013 try operations in other ways: command line, different parts of the GUI, etc., just in case you get that extra clue you need.<\/li>\n<\/ol>\n
    Hope that helps!<\/p>\n
    \n
    Oh, don’t forget – it was my birthday recently and I’m giving away a copy of my book. To enter the competition, click here<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"
    So I got myself into a bit of a kerfuffle today when I was doing some reboots in my home…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2}},"categories":[6,1181,16],"tags":[1400,667,1398,1399],"class_list":["post-6436","post","type-post","status-publish","format-standard","hentry","category-basics","category-data-domain-2","category-networker","tag-device-is-suspect","tag-nsrmm","tag-sufficient-rights","tag-suspect"],"aioseo_notices":[],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_shortlink":"https:\/\/wp.me\/pKpIN-1FO","jetpack_sharing_enabled":true,"jetpack_likes_enabled":true,"_links":{"self":[{"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/posts\/6436","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/comments?post=6436"}],"version-history":[{"count":4,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/posts\/6436\/revisions"}],"predecessor-version":[{"id":7376,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/posts\/6436\/revisions\/7376"}],"wp:attachment":[{"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/media?parent=6436"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/categories?post=6436"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/tags?post=6436"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}