In OSX it will also create an icon in your home directory.
Symbolic links look like aliases in the Finder, but are not the same thing as true MacOS 9 style aliases (which are a file with some data in them, like the shortcuts in windows). Not sure how you could create such a file on the command line, but symlinks work fine for me.
what I'm trying to do is add an alias to /Library/WebServer/Documents
in the FTPRoot directory on OS X Server.
FTPRoot contains aliases (or symlinks) to various other folders like /Users and so on.
When I create a symlink and then run ls -l it lists with idetical permissions etc as the other symlinks, but when I try and access it remotely through FTP its listed differently:
the links put there by the system show up as follows:
and trying to access it via FTP produced an error.
Can anyone shed anylight on what I'm doing wrong. At the moment I can't access the WebServer folder via FTP so I can't remotely upload anything. I know I could switch FTPRoot to Library/WebServer but there must be another more flexible way.
Can anyone tell me how to open a new Finder window in the Terminal?
All right, that's sarcasm, I admit. I understand using the Terminal for things like changing the UI, or hidden preferences, but to do things that the GUI does easily?
if you're logging into your mac via ftp and looking around, wouldn't symbolic links that point to a file you dont have permissions to access be obscured, perhaps that ??? is a polite way of saying you dont have permission instead of writing PERMISSION denied in the output of you ls command.
Try creating a symbolic link to the "drop box" (I think in your "public" folder) and seeing if you can access that from ftp.
I tried doing something similar by placing a symbolic link to one of my folders in my /sites/ folder then trying to access it via a browser... Access Denied - I dont have permission to access that directory ! what ! yes I do... well I'll learn more about apache some day.
what I'm trying to do is add an alias to /Library/WebServer/Documents
in the FTPRoot directory on OS X Server.
FTPRoot contains aliases (or symlinks) to various other folders like /Users and so on.
When I create a symlink and then run ls -l it lists with idetical permissions etc as the other symlinks, but when I try and access it remotely through FTP its listed differently:
the links put there by the system show up as follows:
and trying to access it via FTP produced an error.
Can anyone shed anylight on what I'm doing wrong. At the moment I can't access the WebServer folder via FTP so I can't remotely upload anything. I know I could switch FTPRoot to Library/WebServer but there must be another more flexible way.
When you connect via ftp, the ftpd you connect to basically does a chroot (see the chroot manpage from the command line). That is, the FTPRoot directory becomes the new '/' directory to the ftp user. This is done for security reasons (you do not want anonymous ftp users to see your real passwd files, be inadvertedly able to modify system binaries or libraries or be able to read other people's files).
Therefore, links to anything outside of that tree do not work. It is not a permissions problem. Whatever you want to be available via ftp, including targets of symbolic links, has to be completely enclosed in the FTPRoot directory tree. For example, if you had a link under FTPRoot to /Users, you would actually have to have a FTPRoot/Users for that to work.
On most Unix boxes, when you set up ftp, you have to copy things like dummy passwd and group files in to ~ftp/etc and copy binaries and libraries. See the ftpd manpage under 'Setting up a restricted ftp subtree' for more details.
well, what nguyenhm16 said is right, but not all ftp servers use chroot. it could be a simple problem with the ln command though. when you created the symbolic link, did you give the full or relative path to the destination folder? (Did the destination path start with a slash?) If it was a relative path, then you have to make sure that the relative path is still in place. If its absolute, make sure that the destination really exists. Also, if the destination contains spaces, make sure you correctly quoted them when you did the ln command, ie:
Code:
ln -s '/path/to/look space/' hereIsMyLinkName
you can test this by dropping into terminal.app, and ls'ing the directory (not ftp'ing into the directory, but just *sh'ing). instead of '???' it should mention what the actual path of the link is.
Can anyone tell me how to open a new Finder window in the Terminal?
All right, that's sarcasm, I admit. I understand using the Terminal for things like changing the UI, or hidden preferences, but to do things that the GUI does easily?
Carry on..
It may be that he's not sitting in front of the machine at the time that he needs to make the link.
For instance, setting the Firewall options in MacOS X Server is easy while at the GUI. But I needed to modify them from across a continent a couple of weeks ago, so I had to go digging for where the prefs file is located in the Terminal over an ssh connection.
It's not a silly question by any means.
(And BTW... try 'open /Applications' and see what happens.)
Can anyone tell me how to open a new Finder window in the Terminal?
All right, that's sarcasm, I admit. I understand using the Terminal for things like changing the UI, or hidden preferences, but to do things that the GUI does easily?
Carry on..
to people who speak to me like that I say f**k you f**k you.
try doing it on a headless server and you'll see why you need to use the command line
The ftpd shipped w/ MacOS X is lukemftpd, a drop in replacement for the 4.4BSD ftpd, which does use chroot.
Plus the manpage says it does.
ah, yes. but we don't know if the original poster installed a different ftp server. although, i guess it is a safe assumption that he is using the luke made ftp daemon.
Comments
If you want to read about them then open the terminal and type "man ln" of course no quotes
In OSX it will also create an icon in your home directory.
Originally posted by cybermonkey
You can use ln -s /Loaction/of/file aliasname
In OSX it will also create an icon in your home directory.
Symbolic links look like aliases in the Finder, but are not the same thing as true MacOS 9 style aliases (which are a file with some data in them, like the shortcuts in windows). Not sure how you could create such a file on the command line, but symlinks work fine for me.
in the FTPRoot directory on OS X Server.
FTPRoot contains aliases (or symlinks) to various other folders like /Users and so on.
When I create a symlink and then run ls -l it lists with idetical permissions etc as the other symlinks, but when I try and access it remotely through FTP its listed differently:
the links put there by the system show up as follows:
drwxrwxr-x 1 root admin <creation date> Users
but my symlink show as follows
lrwxr-xr-x 1 root admin 18 Jan 5 11:18 WebServer -> ???
and trying to access it via FTP produced an error.
Can anyone shed anylight on what I'm doing wrong. At the moment I can't access the WebServer folder via FTP so I can't remotely upload anything. I know I could switch FTPRoot to Library/WebServer but there must be another more flexible way.
All right, that's sarcasm, I admit. I understand using the Terminal for things like changing the UI, or hidden preferences, but to do things that the GUI does easily?
Carry on..
if you're logging into your mac via ftp and looking around, wouldn't symbolic links that point to a file you dont have permissions to access be obscured, perhaps that ??? is a polite way of saying you dont have permission instead of writing PERMISSION denied in the output of you ls command.
Try creating a symbolic link to the "drop box" (I think in your "public" folder) and seeing if you can access that from ftp.
I tried doing something similar by placing a symbolic link to one of my folders in my /sites/ folder then trying to access it via a browser... Access Denied - I dont have permission to access that directory ! what ! yes I do... well I'll learn more about apache some day.
Originally posted by bluedalmatian
what I'm trying to do is add an alias to /Library/WebServer/Documents
in the FTPRoot directory on OS X Server.
FTPRoot contains aliases (or symlinks) to various other folders like /Users and so on.
When I create a symlink and then run ls -l it lists with idetical permissions etc as the other symlinks, but when I try and access it remotely through FTP its listed differently:
the links put there by the system show up as follows:
drwxrwxr-x 1 root admin <creation date> Users
but my symlink show as follows
lrwxr-xr-x 1 root admin 18 Jan 5 11:18 WebServer -> ???
and trying to access it via FTP produced an error.
Can anyone shed anylight on what I'm doing wrong. At the moment I can't access the WebServer folder via FTP so I can't remotely upload anything. I know I could switch FTPRoot to Library/WebServer but there must be another more flexible way.
When you connect via ftp, the ftpd you connect to basically does a chroot (see the chroot manpage from the command line). That is, the FTPRoot directory becomes the new '/' directory to the ftp user. This is done for security reasons (you do not want anonymous ftp users to see your real passwd files, be inadvertedly able to modify system binaries or libraries or be able to read other people's files).
Therefore, links to anything outside of that tree do not work. It is not a permissions problem. Whatever you want to be available via ftp, including targets of symbolic links, has to be completely enclosed in the FTPRoot directory tree. For example, if you had a link under FTPRoot to /Users, you would actually have to have a FTPRoot/Users for that to work.
On most Unix boxes, when you set up ftp, you have to copy things like dummy passwd and group files in to ~ftp/etc and copy binaries and libraries. See the ftpd manpage under 'Setting up a restricted ftp subtree' for more details.
ln -s '/path/to/look space/' hereIsMyLinkName
you can test this by dropping into terminal.app, and ls'ing the directory (not ftp'ing into the directory, but just *sh'ing). instead of '???' it should mention what the actual path of the link is.
Originally posted by francisG3
Can anyone tell me how to open a new Finder window in the Terminal?
All right, that's sarcasm, I admit. I understand using the Terminal for things like changing the UI, or hidden preferences, but to do things that the GUI does easily?
Carry on..
It may be that he's not sitting in front of the machine at the time that he needs to make the link.
For instance, setting the Firewall options in MacOS X Server is easy while at the GUI. But I needed to modify them from across a continent a couple of weeks ago, so I had to go digging for where the prefs file is located in the Terminal over an ssh connection.
It's not a silly question by any means.
(And BTW... try 'open /Applications' and see what happens.)
Originally posted by Kickaha
(And BTW... try 'open /Applications' and see what happens.)
Haha
Originally posted by thuh Freak
well, what nguyenhm16 said is right, but not all ftp servers use chroot.
Running 'strings /usr/libexec/ftpd' reveals the following:
$NetBSD: skeleton.c,v 1.14 1997/10/20 03:41:16 lukem Exp $
The ftpd shipped w/ MacOS X is lukemftpd, a drop in replacement for the 4.4BSD ftpd, which does use chroot.
Plus the manpage says it does.
Originally posted by francisG3
Can anyone tell me how to open a new Finder window in the Terminal?
All right, that's sarcasm, I admit. I understand using the Terminal for things like changing the UI, or hidden preferences, but to do things that the GUI does easily?
Carry on..
to people who speak to me like that I say f**k you f**k you.
try doing it on a headless server and you'll see why you need to use the command line
Originally posted by bluedalmatian
to people who speak to me like that I say f**k you f**k you.
See, now we know you're not a *REAL* geek... you didn't say 'fsck you fsck you.'
Originally posted by nguyenhm16
Running 'strings /usr/libexec/ftpd' reveals the following:
$NetBSD: skeleton.c,v 1.14 1997/10/20 03:41:16 lukem Exp $
The ftpd shipped w/ MacOS X is lukemftpd, a drop in replacement for the 4.4BSD ftpd, which does use chroot.
Plus the manpage says it does.
ah, yes. but we don't know if the original poster installed a different ftp server. although, i guess it is a safe assumption that he is using the luke made ftp daemon.