Hi All, Im having an issue with symbolic links permissions with an ocfs2 parition Basically standard symbolic links lose the owner/group information: ie say i have two nodes node1, node2. Both have an ocfs2 partition mounted at /opt I create a symlink on node1: node1:# ln -s /opt/file /opt/link node1:# ls -lah link lrwxrwxrwx 1 root root 9 2008-04-15 15:35 link -> /opt/file I check node2: node2:# ls -lah link lrwxrwxrwx 1 root root 9 2008-04-15 15:35 link -> /opt/file All looks good if i change the owner of the link using chmod: node1:# chown -h user1 /opt/link node1:# ls -lah link # ls -lah link lrwxrwxrwx 1 user1 root 9 2008-04-15 15:35 link -> /opt/file and on node2: node2:# ls -lah link # ls -lah link lrwxrwxrwx 1 user1 root 9 2008-04-15 15:35 link -> /opt/file So now i unmount the ocfs parition on node1, then remount it and check the file again: node1# umount /opt node1# mount /opt node1# ls -lah /opt/link lrwxrwxrwx 1 root root 9 2008-04-15 15:35 /opt/link -> /opt/file Note i have also tested creating the symbolic link as a different user rather than chowning the symlink directly, the results are the same, in which it loses the owner information after remount Note that the owner has changed back to root? Note that standard files do not have this issue Im relatively new to ocfs, so im not sure what other info is needed, Im running debian 4.0 with 2.6.18-6-686 #1 SMP Sun Feb 10 22:11:31 UTC 2008 i686 GNU/Linux and using ocfs-tools 1.2.1-1.3 Cheers Brendan Beveridge
On Tue, Apr 15, 2008 at 03:59:19PM +1000, Brendan Beveridge wrote:> if i change the owner of the link using chmod: > node1:# chown -h user1 /opt/link > node1:# ls -lah link > # ls -lah link > lrwxrwxrwx 1 user1 root 9 2008-04-15 15:35 link -> /opt/file > and on node2: > node2:# ls -lah link > # ls -lah link > lrwxrwxrwx 1 user1 root 9 2008-04-15 15:35 link -> /opt/file > > > So now i unmount the ocfs parition on node1, then remount it and check > the file again: > node1# umount /opt > node1# mount /opt > node1# ls -lah /opt/link > lrwxrwxrwx 1 root root 9 2008-04-15 15:35 /opt/link -> /opt/fileI just checked, and this does indeed happen. My best guess? We don't provide ->setattr() for symlinks. Most filesystems don't. They let the regular inode_setattr() handle it, which calls mark_inode_dirty(). When that dirty inode is written, it hits disk. I'm guessing that our dirty handling, which is slightly different, doesn't work here. Mark might have a quick idea, or I'll look more when I get back from vacation.> Note that the owner has changed back to root? > Note that standard files do not have this issueOut of curiosity, why do you want to do this? Symlinks are always 777. Joel -- "Senator let's be sincere, As much as you can." Joel Becker Principal Software Developer Oracle E-mail: joel.becker at oracle.com Phone: (650) 506-8127