Hi, I’m a migrant from 1&1 and trying to get used to the way DH does things.
I have created a new USER and logged in to the FTP account using FireFTP. There are several directories already there, namely:
I want this account/directory to exchange files with my suppliers (i.e. not to actually appear on a website). Do I need these extra files/directories? What is their purpose? Will there be a problem if I delete them?
Also, I’m a bit confused about the server name. Should the server be .dreamhost.com or ftp. At the moment only kratos.dreamhost.com works but this seems illogical as (a) I understand the server part could change over time and (b) the user names would have to be unique across the whole DH community
Thaks for the welcome. I think I understand the directory structure from the root for domains and subdomains. However the question related to a new USER that was added. When logging in using that USER’s FTP credentilas I see:
Are those the same ones that are being seen in the root but access to the domain directory is removed for this new user? Or am I in a completely new directory with new copies of those files/directories. And are those files/directories necessary anyway?
Yes that’s exactly what I want to do: have suppliers upload and download files with me without having to go through mail servers.
So is my new FTP account actually giving access to my root but without access to the domain directory, or am I in a new location altogether? If the former, then how can I protect those important files from accidental deletion by my suppliers.
If you create domains under that user, they will all appear as subfolders of the same user account.
That is unless you create new users for each domain - i generally keep each of my client’s websites under the same user, so in effect they’re grouped.
I however do not give them ftp details…
I’m not sure how you’re going to do this. I would advise you to create a folder within the user’s account which will serve as the ftp root… i’m not sure how you’ll be able to “lock” the ftp user to that folder though.
Hopefully someone else can help you here. I’ve had a look in Google for you, but nothing has jumped out at me
If you don’t get a satisfactory response here, your best bet is to use the support ticket system in the DH control panel. The DH staff are great and really helpful. If it can be done, they’ll usually give you a code snippet, instructions, links etc.
Sorry i couldn’t sort it out.
If you find out, please post the results here - i’d like to know how to do it myself
Well maybe don’t make to much sense… but what I do is create users accounts for ftp and then create a symlink to their directory on my user that is where the domain runs… this way I have 7 contributors each isolated to their ftp directory (also if you give only ftp permissions to your users they are chrooted to their homes and can’t move to /tmp for say something… if you give them shell access the things are different, there you can activate the extra security (new feature) and/or work with unix groups… a litte extra work but works fine for me).
use VIC3M to get some discount on all plans +10% on storage and bandwith.
Good suggestion from a multiple contributor sense, but the problem still stands in that the client can still delete their own user’s .* files.
I was trying to find a way to prevent the user from having access to the user root via ftp - maybe some sort of redirect on login that forces them to a subfolder, OR restricts them from viewing hidden/system files.
I take a different approach to this altogether. I use a "filemanager’ or “upload” script, giving them limited ability to manipulate files within a given directory and that directory’s subdirectories. I protect access to these scripts with apache authentication , so that only authorized users can manipulate the files.
My user ends up owning all the files - which is a great convenience in many ways when running under suEXEC.
My “users” never get FTP or shell access - solves a myriad of (l)user related PBTKAC problems
If they need to be able to delete/manage “their” files, they get a “filemanager” while if they only need to “upload” files, they get an “upload only” script.
This works well for me and solve a lot, if not all, the issues you mention.
The thought of a file upload script actually did cross my mind, but I thought it might have been a bit like taking a sledgehammer to a walnut. Having said that, I didn’t consider the benefits you raised.
All things considered, I agree that a file upload manager script would do the trick - and i reckon you would solve all of the issues i raised.
Expanding upon this, you could even have the one script handling ALL of your clients, suppliers, etc, each with their own login details, which determines the dir of the files they are presented with… sort of like a reusable file dump for each client.
One possible caveat though - Is there a decent file upload script that supports drag and drop (like the Zoom gallery one in Joomla)? I know it’d be a pain to have to “browse” for each file to upload, and a drag & drop interface would be lovely!
[quote]Is there a decent file upload script that supports drag and drop (like the Zoom gallery one in Joomla)? I know it’d be a pain to have to “browse” for each file to upload, and a drag & drop interface would be lovely!
I don’t know, but with all the code that is “out there” one wold think so, wouldn’t you?
Hi rlparker, I’ve seen your suggestion in other posts. My concern has been twofold: the lack of drag’n’drop as indicated by digitalvibe but also the lack of a decent protocol covering the data transfer.
I’m not very familiar with this stuff but I do know that one of the beauties of FTP is the ability to resume uploading/downloading after an interruption. Would this be possible with uberUploader for example?
Also, my biggest concern is to provide an area where I can upload files and then my suppliers and customers can download them again. This will not be anything to do with websites, just a file transfer area.
Those are both very valid concerns, and I’m not sure my suggested approach could be easily adapted to address either of them.
No, it is not possible with uber-uploader. There has been some discussion on the sourceforge forum for the project about the addition of such a feature, but the author has not undertaken to add that ability to the program (and has indicated he feels it would be very difficult to do so).
Additionally, a “quick search” through the more popular script archives produced only one upload script that claims it can do this (an ASP application); there may well be one, or more, out there - I just have not located it.
I have not searched for a “drag and drop” interface implementation, so I can’t comment further on that, though I suspect something with a “nicer” user interface might be “out there some where”.
In my situations, this function is usually used to send a very few files at a time, and I have found that the uber-uploader interface, which allows"several" files to be included by multiple “browses”, has been acceptable for my users, but I understand that your needs may be different.
That is stated a little bit differently than your earlier posts, and the difference could be significant.
If you are doing all the uploading, and only require that the system be set up so the your “suppliers and customers can download them again”, then just setting aside a directory under your own user in a web accessible location should address that need (you can connect via an FTP client with whatever user interface you like and enjoy the resume transfer function).
OK after a bit of experimentation it’s actually very simple.
It appears that each new user created is given it’s own FTP directory. Although there are , and other files in this directory, these files can be safely deleted if the directory is only being used for FTP rather than web hosting.
The directory is isolated and has no access to the root directory or any of the website directories. So I simply give everyone the FTP logon details for this new user and they can happily read and write to that directory and no other.
Thank you for your input into this though - I appreciate the help.