<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic directory ownership and SMO in Data Protection</title>
    <link>https://community.netapp.com/t5/Data-Protection/directory-ownership-and-SMO/m-p/56649#M5877</link>
    <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;I created some new volumes, and qtrees on the filer and the exports got created as well.&lt;/P&gt;&lt;P&gt;I modified the /etc/fstab on the linux host , created the directories, subdirectories, and modified the ownership. In my case it had to be owned by oracle:dba instead of root:root&lt;/P&gt;&lt;P&gt;Everything looks good up until I mount those newly created volumes with their mount points.&amp;nbsp; Once I mount them (mount -a), the owneship switches to root:root.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Anyone has faced this same issue?&amp;nbsp; How did you get it resolved?&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
    <pubDate>Thu, 05 Jun 2025 06:06:31 GMT</pubDate>
    <dc:creator>ZEIDAN_ATA</dc:creator>
    <dc:date>2025-06-05T06:06:31Z</dc:date>
    <item>
      <title>directory ownership and SMO</title>
      <link>https://community.netapp.com/t5/Data-Protection/directory-ownership-and-SMO/m-p/56649#M5877</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;I created some new volumes, and qtrees on the filer and the exports got created as well.&lt;/P&gt;&lt;P&gt;I modified the /etc/fstab on the linux host , created the directories, subdirectories, and modified the ownership. In my case it had to be owned by oracle:dba instead of root:root&lt;/P&gt;&lt;P&gt;Everything looks good up until I mount those newly created volumes with their mount points.&amp;nbsp; Once I mount them (mount -a), the owneship switches to root:root.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Anyone has faced this same issue?&amp;nbsp; How did you get it resolved?&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Thu, 05 Jun 2025 06:06:31 GMT</pubDate>
      <guid>https://community.netapp.com/t5/Data-Protection/directory-ownership-and-SMO/m-p/56649#M5877</guid>
      <dc:creator>ZEIDAN_ATA</dc:creator>
      <dc:date>2025-06-05T06:06:31Z</dc:date>
    </item>
    <item>
      <title>Re: directory ownership and SMO</title>
      <link>https://community.netapp.com/t5/Data-Protection/directory-ownership-and-SMO/m-p/56654#M5878</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;What you describe is normal.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;You modified the permissions on the directory structure on the client prior to mounting - all you did was set the perms on the mount point.&amp;nbsp; Volumes/qtrees are created with root:root by default (if using unix permissions, of course), and the acls of the remote filesystem are what show up on the mount point after a mount.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;You need to mount everything up, then change the permissions and ownership.&amp;nbsp; If you then mount the volume on another host, the permissions will already be set.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Hope that helps.&lt;/P&gt;&lt;P&gt;Bill&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Mon, 01 Apr 2013 20:37:47 GMT</pubDate>
      <guid>https://community.netapp.com/t5/Data-Protection/directory-ownership-and-SMO/m-p/56654#M5878</guid>
      <dc:creator>billshaffer</dc:creator>
      <dc:date>2013-04-01T20:37:47Z</dc:date>
    </item>
    <item>
      <title>Re: directory ownership and SMO</title>
      <link>https://community.netapp.com/t5/Data-Protection/directory-ownership-and-SMO/m-p/56659#M5879</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Bill, &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Thanks for replying.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;If I mount everything and then try to change ownership, I get the following:&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;# chown -R oracle:dba LVTEST LVDEV&lt;/P&gt;&lt;P&gt;chown: changing ownership of `LVTEST/redob/.snapshot': Read-only file system&lt;/P&gt;&lt;P&gt;chown: changing ownership of `LVTEST/exp/.snapshot': Read-only file system&lt;/P&gt;&lt;P&gt;chown: changing ownership of `LVTEST/arch/.snapshot': Read-only file system&lt;/P&gt;&lt;P&gt;chown: changing ownership of `LVTEST/redoa/.snapshot': Read-only file system&lt;/P&gt;&lt;P&gt;chown: changing ownership of `LVTEST/ctrl/.snapshot': Read-only file system&lt;/P&gt;&lt;P&gt;chown: changing ownership of `LVTEST/data/.snapshot': Read-only file system&lt;/P&gt;&lt;P&gt;chown: changing ownership of `LVDEV/redob/.snapshot': Read-only file system&lt;/P&gt;&lt;P&gt;chown: changing ownership of `LVDEV/exp/.snapshot': Read-only file system&lt;/P&gt;&lt;P&gt;chown: changing ownership of `LVDEV/arch/.snapshot': Read-only file system&lt;/P&gt;&lt;P&gt;chown: changing ownership of `LVDEV/redoa/.snapshot': Read-only file system&lt;/P&gt;&lt;P&gt;chown: changing ownership of `LVDEV/ctrl/.snapshot': Read-only file system&lt;/P&gt;&lt;P&gt;chown: changing ownership of `LVDEV/data/.snapshot': Read-only file system&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Mon, 01 Apr 2013 20:49:10 GMT</pubDate>
      <guid>https://community.netapp.com/t5/Data-Protection/directory-ownership-and-SMO/m-p/56659#M5879</guid>
      <dc:creator>ZEIDAN_ATA</dc:creator>
      <dc:date>2013-04-01T20:49:10Z</dc:date>
    </item>
    <item>
      <title>Re: directory ownership and SMO</title>
      <link>https://community.netapp.com/t5/Data-Protection/directory-ownership-and-SMO/m-p/56662#M5880</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;That should be fine.&amp;nbsp; You won't be able to modify the .snapshot directories because (like the error says) they are read only.&amp;nbsp; If you look at the LVTEST and LVDEV directories and sub directories, you should see them with the permissions you specified.&amp;nbsp; .snapshot will always be root:root:777 I think - but the snapshot content, under .snapshot/&amp;lt;snap_name&amp;gt;/, will mirror the permissions on the live filesystems at the time the snapshot was taken.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Bill&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Mon, 01 Apr 2013 20:55:32 GMT</pubDate>
      <guid>https://community.netapp.com/t5/Data-Protection/directory-ownership-and-SMO/m-p/56662#M5880</guid>
      <dc:creator>billshaffer</dc:creator>
      <dc:date>2013-04-01T20:55:32Z</dc:date>
    </item>
    <item>
      <title>Re: directory ownership and SMO</title>
      <link>https://community.netapp.com/t5/Data-Protection/directory-ownership-and-SMO/m-p/56667#M5881</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Great , thank you.... It was throwing me off seeing the output I pasted last.&lt;/P&gt;&lt;P&gt;Thanks again Bill&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Mon, 01 Apr 2013 21:11:53 GMT</pubDate>
      <guid>https://community.netapp.com/t5/Data-Protection/directory-ownership-and-SMO/m-p/56667#M5881</guid>
      <dc:creator>ZEIDAN_ATA</dc:creator>
      <dc:date>2013-04-01T21:11:53Z</dc:date>
    </item>
  </channel>
</rss>

