Messages posted by: spinkb

Not really... There are likely some things that could be done, but there are probably better tools out there meant for that. CrushFTP is really meant more for the file transfer aspect rather than managing snippets for Q and A.

Sorry,
Ben

For the WebInterface listings, yes. See the User Manager, WebInterface, customization list for the date format controls.

Thanks,
Ben

Please alter that init script to see if this resolves it.

Instead of:
CrushFTP.jar

use:
plugins/lib/CrushFTPJarProxy.jar

Let me know,
Ben

Joel,

This is something you need to fix ASAP. This is an OSX issue where the server was offline while someone was uploading, so CrushFTP had to create the directory structure to the location the user was writing to. This is why you have a /Volumes/Project/ folder on your system. However, once you mounted the network server again, the OS couldn't use the former path of /Volumes/Projects/ since it was in use, so it made a /Volumes/Projects-1/

That is currently the *real* location, all the rest of the data that is in Projects is sitting on your local drive, orphaned from being on the server.

Go to the OS Finder, Go to the 'Go" menu, and Open folder. Enter the path "/Volumes/". This will open the window showing you this. Move the Projects folder to your desktop.

Now unmount the network server, then mount it again and verify it shows up in /Volumes/ as Projects and not as Projects-1 like it was.

Now you can manually merge the stuff that is in Your "Projects" folder on your desktop with the real one on the server.

Thanks,
Ben

And if you check your crushftp_init.sh script, is it launching with the CrushFTP.jar or the CrushFTPJarProxy file?

Thanks,
Ben

What jars do you have in your plugins/lib folder?

Thanks,
Ben

Drop me an email directly to debug this further.

--Ben

Are you sure? Its working for us here...

Give it a bit more time to display the results of the report maybe...

A little confused on this reply.

So things are fine now?

When I have tested this here, the last day is always working for me. I have activity on 5/8, and last day chooses 5/7 as its date and it runs showing my activity.

So this seems OK as far as we can tell...

If you are running as root for the server, then yes. If not, then the file is going to be owned by whatever user that is running CrushFTP.

Go to the user manager, default user, misc section and set the default owner, group, and privs for uploaded files. Those will be used for all new files from then on.

Thanks,
Ben

If you want to run as non root, edit the crushftp_init.sh script and configure the alternate username you will be using.

Then run the script to start CrushFTP.

But you need to change all your ports to be higher than 1024, and use redirection through other means to get ports lower than 1024 to point to the higher version of the port number. This is what the FAQ entry is covering.

In general, its a *very* rare case where its really beneficial for someone to run as non root.

Thanks,
Ben

Re-download CrushFTP, and don't use Window's to unzip. Win2k3 has a zip bug that prevents unzipping the folder properly. Use 7zip, or winzip, or another newer version of windows.

Your folder is missing items as windows failed to unzip it properly.

Thanks,
Ben

Click update now to get to 6.3.0_50. Then see if the report issues remain.

Thanks,
Ben

What exact version of CrushFTP are you using?

Have you set the stats to go to an third party external database?

Thanks,
Ben

Replies to dead topics don't cause notifications. So I just happened to see this forum post by accident. Post a new topic instead of adding on to an already completed topic.

This is not WebDAV. WebDAV does not use a web browser at all. This is just the WebInterface, or browser interface.

What browser were you using?

What does writing overtop itself in a loop mean? Can you email me directly some screenshots of the issue if its still happening in the latest version?

Thanks,
Ben

Florian,

This has already been corrected in current builds. So if you update now, the sub admins can see the templates.

Just click update now to force it to a newer build of 6.3.

Thanks,
Ben

It's not the VFS loosing connectivity, its windows loosing connectivity. CrushFTP needs the file system to be working...and windows has lost the connection. You have a windows issue...

Why not run CrushFTP on your Mac, and use AFP to mount the drives, or SMB on the Mac OS...?

Or use CrushFTP to do a FTP styled connection to the NAS server.

Thanks,
Ben

These sort of changes are the kind of changes that take a day or two to be made, and a new build is created right then including the new features. No long delays waiting for a release. CrushFTP has new versions released daily. When a feature is done, its released.

The task sequence goes something like this.
uservariable: the_folder = {real_parent_path}
exclude: all
find: {the_folder}
jump, return: {name} = triggerfile.txt
uservariable has_trigger = true
jump, return has_trigger = true
do your task items with the files that were found
end

So you execute this event on upload, that gets the folder that is being uploaded to, then clears the list of tracked items, does a find to find all items in the folder, checks for the trigger file, sets a variable that its found, etc. This logic though relies on the enterprise license as conditional 'Jump' is only supported on enterprise licenses.

If there ends up being something about this scenario that doesn't entirely cover your business need, this is where I indicated that I would add the necessary features.

So I believe things are handled already, just need the enterprise license.

Thanks,
Ben

Hi Mito.

Yes, all of these scenarios are possible. One of the key things you get with the enterprise license is the Job manager. Its lets you see the results easily of individual jobs.

The other big benefit is that this sort of setup scenario would be part of an enterprise "initial configuration" period. So you would receive direct help in configuring your specific scenarios exactly.

Public keys, FTPES, etc...all supported. Trigger files can be used, but it creates more complexities. I may do some custom changes to support the usage you have planned on trigger files too as part of an enterprise license.

In short, I see no issues with what you have described. There is also some *major* enhancements coming to the job scheduling and designing system in CrushFTP for working with CrushTask. This too is an enterprise only feature.

Thanks,
Ben

On the right side of the individual setting area is a 'Make Sticky' button. Click it, and that section will always be displayed, even if the user is inheriting from the default user.

The latest build 6.3.0_43 now has this ability. Please test it out for me and see how it works for you.

The Email task item supports some new variables.

http://domain.com/{share_move_30}
http://domain.com/{share_move_15}
http://domain.com/{share_reference_45}
http://domain.com/{share_copy_7}
http://domain.com/{share_copy_22}

etc.

First part is the {share, second part is the type of share...move/copy/reference, and final part is days until expiration.

Thanks,
Ben

1.) No one looks at logs anyway...1% of people or less even know that these exist for FTP, and SFTP has no way of returning this information either. So no point. The WebInterface gives a good message though. And a ban means the socket is disconnected as soon as we see its IP. No messages, nothing, the server is dead to them. I don't want to change that and give a message after a user is banned.

2.) The WebInterface already does this. It warns you that you are going to get banned if you keep trying bad logins, then when you are banned and it can't connect anymore, it suggests that you probably have been banned at this point.

3.) I added protection in CrushSync. CrushFTP drive already tests your password one time before closing the "Connect" window. Latest build of CrushSync will popup a user/pass box on the local machine fi the login fails...it won't keep hammering the server. But the desktop UI doesn't exist much...so it relies on the webui for everything. And fi the password is wrong, then the webui can't do anything, it can't monitor, control, etc. Its dead at that point until the client login is fixed.

Can you email me directly?

Send me a screenshot of your plugin configuration...might take a couple to cover the entire height of the plugin's panel.

Thanks,
Ben

The OU doesn't matter.

What its doing is the user's credentials are checked in LDAP, then the users folder access rights, and other settings are loaded from the matching user in the user manager. So this means you must make the username each time in the user manager too.

You can configure a blank password, and then block blank passwords from being used in the prefs, encryption, passwords tab.

--Ben

I understand its difficult. The LDAP configuration is different for everyone's servers though, so i try and give you the buttons to test and try it out to figure out what your configuration needs. The defaults are generally fairly close to be right for an AD server.

No...

You need a specific kind of client that allows you to set the public key for a server before you connect to it. You don't have that...and I don't know of any clients to recommend. So you can't test if the public key is pre-approved for the server.

Its not important. Just give your customer both of those public key files.

This looks like you are connecting to the OS X OpenSSH server...running on port 22.

This isn't CrushFTP messages...

Set CrushFTP back to port 2222.

Then connect to port 2222.

Does that work? If so, stop your OS X remote login process in the system prefs, sharing control panel. Then you can change CrushFTP to use port 22. But first verify with port 2222.

What shows in the log of CrushFTP when you try?

What exact messages does the client log show?

Turn off the require public key.

Don't change any server settings. Everything was correct before you made a change.

You aren't paranoid like the other client, so you can just connect. The client will ask fi you trust the server's key, and you click yes. Your client refuses to click yes...they want the key from you ahead of time, and that way they don't have to click yes in whatever client they are using.

Thanks,
Ben

Let me know what the system.log has.

Thanks,
Ben

What are you trying to do with that key? That .pub file is something you email to the client who will be connecting, and they use it to "trust" you in advance.

You shouldn't be trying to sue that for anything yourself...

Yes, SFTP is enabled.

By default the port is 2222, and not 22. So use the right port, or change CrushFTP to use port 22.

Thanks,
Ben

The LDAP server is complaining about the format of the username you attempted. Try without the leading domain\ on it, or try user@domain, etc. See if those work.

Thanks,
Ben

Under no circumstance can CrushFTP ever cause the issues you have described. Its absolutely impossible. I understand that you think its CrushFTP causing your issues, but I can assure you that is a wrong assumption.

CrushFTP does not alter your system files. It does not install dynlib files. It does not change system files, symlinks, etc. Nothing is changed.

It uses Apple's "launchctl" to register the daemon, or to remove the daemon. This is not some magical complicated process, and its the official supported method form apple for an app to install a reference the to the daemon. All it does is at boot, the OS knows that you want to run CrushFTP, without the GUI. But fi the app isn't there, or something isn't working with the app, etc...it doesn't matter. It wouldn't affect things. And this start of the app wouldn't happen till the end of the boot process, so nothing related to CrushFTP could be going on where you describe.

There is also no possible way for CrushFTP to crash the machine. The worst case CrushFTP can do is crash its virtual machine it runs inside of, the Java Virtual Machine (JVM). The most is can do is cause the JVM to exit. Nothing more.

So what you have described indicates that there are some corrupt OS files, or bad RAM, or corrupt file system, or failing hardware in some way.

Think about it like this. The *exact* same CrushFTP code runs in every OS. It works in every OS. There isn't something that knows its in OS X and operates in a different way that could cause a crash.

The issue is not CrushFTP, and as long as you focus on what CrushFTP is doing to your system, you will never be any closer in finding out what is really wrong.

Boot into single user mode, take a look at the OS system.log file, or boot from another drive, copy that file off somewhere and look at it more. Look for errors when the machine is booting, or around when things stopped working. It holds the key into what is failing. At this point, CrushFTP is doing no more than a text file does sitting on your machine. Its a document, its not running, its doing nothing. Get the logs and we can see what your machine's issue is.

Thanks,
Ben

SSL is unrelated to SSH. So just need to clear that up for you first. No certs either, just keys.

They want your public key, int he CrushFTP folder are two files ending in ".pub". Give them both of those. *DO NOT* give them the files that have no extension, those are your super secret private keys.

You don't need to do anything else. Just run CrushFTP, click start temporary server, and its working. You then should register, and install the daemon.

Thanks,
Ben

New versions of CrushFTP now default the alert to have these values. Most other alert types are very basic and are just a static message as the variables don't apply.

But there is a list of all the user type variables on the wiki.

http://www.crushftp.com/crush6wiki/Wiki.jsp?page=Server%20Variables

Thanks,
Ben

That is an interesting thing to add, but at this time, no it can't be done. Will add to my todo list though.

Thanks,
Ben

They do if you mis-type the password even one time...so its dangerous.

You can adjust that and remove admin from the instant ban list...but its not a good idea to use that username for daily administration as robots are always trying to use it.

--Ben

It doesn't need external access at all.

Change the ports to use the LAN IP to bind to instead of the "lookup" IP.

Your current issue with the banning is that you got your IP banned. Go to the prefs, banning tab and remove the "D" entry for your IP.

In the future, be careful not to exceed one of the rules on that screen.

Thanks,
Ben

I understand what your saying, but technically, crush doesn't care about one set of users versus another. So fi its different users, from my perspective, I really suspect the drill down issue of them not understanding they hadn't changed locations when they tried...?

Definitely try the latest build too just to make sure everything is up to date. 6.3.0_30+. Just click update now on the about tab.

Thanks,
Ben

Do not use the arrow expansion on the left. Only click on the folder to open it and get inside of it.

Doing this can you see if you still have issues making a folder?

I think the issue is that you drilled down, but you still weren't inside the folder.

Both transmit and fetch have logs. Can you get the logs to see what the messages are?

This really seems like you're connecting to another FTP server. Like maybe you are connecting to the built-in OS X FTP server, and not crush FTP.

Port 20 is not used. Its a common misunderstanding people have.

For FTP, the relevant ports are 21 and 2000-2100. Not 21000. Just 100 ports. Then set that same range in the CrushFTP PASV port range for the FTP port.

I'm not sure where your issue is at...lets start over. Be *exact*. Do not translate error messages to your interpretation of them. Exact wording, and the exact phrases often tell a lot. Example "connection refused" means a precise thing...but if you tell me you can't login, or can't connect...its lost all the meaning that the words "connection refused" had.

So do this. View the log in CrushFTP. Open your FTP client, and try connecting using the LAN IP. (Don't mess with the external IP for now, you'll do that later.) What exactly does the client log show, or error messages say? What exactly does the server log show? Don't translate anything...word for word info please.

If it works using the LAN, then use the diagnostic page to test FTP. http://crushftp.com/diagnostics.jsp

Thanks,
Ben

Those log entries are for your HTTP admin browser session monitoring things. Nothing else. You would see FTP mentioned if it was FTP.

So this log shows no attempts. So you know they never reached CrushFTP. A firewall, or router, or bad IP sent them to somewhere else.

So not a CrushFTP issue...networking issue.

{real_path}

I think that is the variable you want. The help tab in CrushTask gives you a complete list of variables.

Thanks,
Ben

Pictures are worth a thousand words...

My cache is called "kbs". A file will be created called "kbs" on the third task item, and used for all future runs.

The cache is used in the 2nd item to filter out items that are found with prior runs that we have done.

(Screenshots didn't post in order...but you can see the order of the task items.)

Thanks,
Ben

What exactly shows up in the CrushFTP log when a FTP client attempts to connect?

Paste the log entries here.

Thanks,
Ben

Port 22 should be used for SFTP, unless you already have it in use by OpenSSH for example. That is why CrushFTP defaults to 2222 to avoid a conflict. But by all means, if its not in use, change it to 22.

Port 990 is FTPS Implicit. Don't use it.

portforward.com has examples for nearly every router out there on how to forward a port. That is all that was meant when he said to check the website method.

Thanks,
Ben

I would suggest another approach...

The NAS likely supports FTP or SFTP access to it.

Create a VFS item in CrushFTP using that protocol and put in the user/pass there.

ftp://user:pass@nas_ip/

Otherwise you need to mess around with windows networking, join the NAS and your machine in the same domain or work group, and set the service to run as a specific user account so it can access that folder.