has anybody had experience doing cifs.home_dir this way? i am having a problem. i'm sure i am missing something. the original post was from me and steve losen answered.
~~~~~~~~~~~~~~~~ neil said:
hi,
our homedir structure is /vol/vol0/users/a/adam
we want to use the subst cmd instead of 'net use' because we go below the share. and since we have the first letter of the userid in there we can't use the ontap homedir option.
however, we can't get subst to work as a user.
C:\WINNTSRV>subst q: \filer\u7\k\kusr1 Path not found - \filer\u7\k\kusr1
subst works fine as admin.
We get around this problem by creating a directory with a bunch of symbolic links in it, and making that directory our cifs.home_dir.
You'll need to make the symbolic links on a NFS client.
For example, we have this:
options cifs.home_dir /home/shares
And we have a symbolic link for each user like these:
/home/shares/abc9d -> /h1/a/ab/abc9d /home/shares/fgh8i -> /h1/f/fg/fgh8i
etc.
On our system both /home/shares and /h1 are in our root volume, or else we would have to use paths like /vol/vol1/home/shares and /vol/vol1/h1/a/ab/abc9d.
It's very easy to create all these symbolic links with the unix shell. For example, on our system you could do this:
cd /h1 for x in ?/??; do ( cd $x for loginid in *; do test -d $loginid && ln -s /h1/$x/$loginid /home/shares done ) done
Steve Losen scl@virginia.edu phone: 434-924-0640
University of Virginia ITC Unix Support ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
has anybody had experience doing cifs.home_dir this way? i am having a problem. i'm sure i am missing something. the original post was from me and steve losen answered.
Yes, we have cifs.home_dir pointed at a directory of symlinks, and it's working fine here:
cifs.home_dir /vol/vol0/home/users/%u%/nt,/vol/vol0/home/users
This is pretty neat (for us), as the mere presence of an "nt" subdir in a user's (Unix) homedir will place their Windows homedir in that subdir. If there is no such "nt" subdir, then their top-level Unix homedir will also be their Windows homedir. Different users have different preferencs.
The only glitch I noticed was that initially, the /vol/vol0/home/ directory was a plain directory (not a qtree) on a Unix-style volume, and even though the targets of all the symlinks were NTFS-style qtree's, these auto-generated home shares ended up with Unix security style. This issue was solved by putting the symlinks in a mixed-style qtree (we use the same symlinks for both Windows and Unix users). I did put in an enhancement request about this issue (we're running 6.1R1).
Oh yeah, there is one other part necessary. The symlink.translations file has to be present and accurate, and the symlinks cannot point to targets that are _off_ of the filer. We make the symlinks on an NFS host, with paths relative to the NFS mount points, like this:
adminhost 269# mount | grep home /home on filer:/vol/vol0/home ... adminhost 270# ls -l /home/users/test lrwxrwxrwx 1 root root 32 Nov 5 1997 /home/users/test -> /disk/filer/users/myworkgroup/test adminhost 271# head -3 /disk/filer/etc/symlink.translations # Caution: CIFS should only follow symlinks to directories, # not to files. Windows apps don't know about symlinks. map /disk/filer/users/* /vol/vol0/users/* adminhost 272#
I think there's some interaction with the "cifs.home_dir_namestyle" option, as well, but can't recall exactly what it is. Ours is set to the null string (""), if that matters.
Regards,
thanks
the point about relative paths:
i have cifs.home_dir pointed to /vol/vol0/homelinks
when i mounted the filer from a sun box
i went into /filer/homelinks
and then i did ln -s ../smalltest2/k/kusr1 kusr1
where smalltest2 is a qtree at the same level as homelinks and kusr1 is the uid.
that's the correct way, right?
obviously[after some groaning], linking to /filer//smalltest2/k/kusr1 wouldn't work.
and yes, when homelinks was just a dir, it showed up in nt file properties as a FAT volume. i made it a mixed qtree as you said and now it has ntfs props.
Marion Hakanson wrote:
has anybody had experience doing cifs.home_dir this way? i am having a problem. i'm sure i am missing something. the original post was from me and steve losen answered.
Yes, we have cifs.home_dir pointed at a directory of symlinks, and it's working fine here:
cifs.home_dir /vol/vol0/home/users/%u%/nt,/vol/vol0/home/users
This is pretty neat (for us), as the mere presence of an "nt" subdir in a user's (Unix) homedir will place their Windows homedir in that subdir. If there is no such "nt" subdir, then their top-level Unix homedir will also be their Windows homedir. Different users have different preferencs.
The only glitch I noticed was that initially, the /vol/vol0/home/ directory was a plain directory (not a qtree) on a Unix-style volume, and even though the targets of all the symlinks were NTFS-style qtree's, these auto-generated home shares ended up with Unix security style. This issue was solved by putting the symlinks in a mixed-style qtree (we use the same symlinks for both Windows and Unix users). I did put in an enhancement request about this issue (we're running 6.1R1).
Oh yeah, there is one other part necessary. The symlink.translations file has to be present and accurate, and the symlinks cannot point to targets that are _off_ of the filer. We make the symlinks on an NFS host, with paths relative to the NFS mount points, like this:
adminhost 269# mount | grep home /home on filer:/vol/vol0/home ... adminhost 270# ls -l /home/users/test lrwxrwxrwx 1 root root 32 Nov 5 1997 /home/users/test -> /disk/filer/users/myworkgroup/test adminhost 271# head -3 /disk/filer/etc/symlink.translations # Caution: CIFS should only follow symlinks to directories, # not to files. Windows apps don't know about symlinks. map /disk/filer/users/* /vol/vol0/users/* adminhost 272#
I think there's some interaction with the "cifs.home_dir_namestyle" option, as well, but can't recall exactly what it is. Ours is set to the null string (""), if that matters.
Regards,
-- Marion Hakanson hakanson@cse.ogi.edu CSE Computing Facilities
-
Marion Hakanson -
neil lehrer