The Omni Group
These forums are now read-only. Please visit our new forums to participate in discussion. A new account will be required to post in the new forums. For more info on the switch, see this post. Thank you!

Go Back   The Omni Group Forums > OmniOutliner > OmniOutliner 3 for Mac
FAQ Members List Calendar Search Today's Posts Mark Forums Read

Omni Sync Server with Transmit (Panic Software) [A: bug in Transmit. See thread.] Thread Tools Search this Thread Display Modes
For sync omnioutliner documents between mac and iPad, I use omnisync with finder (Lion) and it works. But I prefer to use Transmit (4.2); more reliable and faster.
Whith the same id and url, it doesn't work
Have you an idea
I try the solution of this thread but it doesn't work too.
If you're the same aglekis on our sync server, try using for the server. Also make sure not to put your username in the server path, it should just be "". Then put "/agelkis/" in the remote path field.

If you're still running into problems, please contact our Support Ninjas at Thanks!
I've made this suggestion before, when the number of servers was apparently smaller. Why not have the OSS divulge this information to the user when logged in to the website?
Thanks a lot Derek. That's me. It works great.
I agree this "whpalmer4". You should show up the right path in our online account.
Sorry for the trouble here - this phenomenon is caused by a bug in one of the open-source frameworks that Transmit uses. Specifically, it can't handle the redirect from to the actual back-end server that the account lives on.

We've discussed the issue with them; they plan to update the version of that framework which Transmit uses eventually, but we don't know when that will be. In the meantime, please let them know you encountered this problem so it stays on their radar screen.

In the vast majority of cases, we want folks using the generic URL, not the one that points at a specific server. When we need to re-balance server populations in the future, anything that depends on reaching the account on that server will break.

Folks encountering this issue can contact and we'll help them out.
So rebalance the load, and those affected can look at the webpage for the new URL they should use. They've already gone through this, so they'll have some idea where to look, unlike the people trying to make it work for the first time, who have no reason to believe that it shouldn't work as is. The current policy inconveniences everyone who needs to discover the post-redirect URL; my suggestion inconveniences only a subset of that group. Better for some, and none are worse off. Surely you are not suggesting that everyone who calls in with this problem will never be moved to a different server, or a support ninja will contact them to help them migrate?
I'm saying that we don't want to encourage folks to depend on a specific server address at all - they should be pointing at

It's useful in this case as a workaround to the bug in Transmit, but we don't want folks building workflows around this, then getting upset if something changes in the future.
Well, it's also necessary to know the redirect target if you're using the Finder to access the OSS from Snow Leopard.

The number of people who are affected by this bug ≥ the number of people who are affected by this bug and won't know what to do if you move them to a different machine. I'll ask my question again: if someone calls in with a problem for which the solution is to provide them the current redirect target for their account, and the support ninja gives them that information, are you going to a) never migrate them to a different server, or b) contact them when you do? If neither, then your concern about someone getting this same information from the website instead of a support ninja is unjustified, because they'll be equally out of luck.
We notify folks when we do migrations.

It is true that there are a few circumstances in which we'll help folks do something we don't want them to do. Like when a bug or missing feature in another product leaves them no other option.

However, my basic point remains: exposing information we don't want folks to be using actually encourages them to do so.

Yes, a very small number of people will need to contact us to resolve issues like this. We're okay with that.
There's an easy way to look up the final URL you get redirected to: just point your web browser at your main Sync Server URL at, and it will be redirected to the appropriate server at You can grab your final URL from the location bar and use it in Transmit, Finder, or any other tool that has trouble handling web redirects.

(WebDAV is the web's standard http protocol, with some extra extensions to cover other common file operations like renaming and locking files.)

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Similar Threads
Thread Thread Starter Forum Replies Last Post
Can't connect to Omni Sync Server via Panic's Transmit [A: bug in Transmit. See thread.] joecab Syncing via Omni Sync Server 5 2012-09-19 11:35 AM
Sync OmniFocus With DropBox? [Not supported, use the free Omni Sync Server instead] Lamike OmniFocus Syncing 26 2011-11-12 06:54 PM
Please add Omni Sync Server support [A: iPhone app supports the server. See thread.] StateMachineJunkie OmniFocus for iPhone 4 2010-11-30 01:29 PM
Custom Perspective Icons lost with Omni Sync Server Sync manuhoff OmniFocus Syncing 0 2010-08-02 11:36 PM

All times are GMT -8. The time now is 07:08 AM.

Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2024, vBulletin Solutions, Inc.