I am trying to create a shared folder for multiple users. Is there a way I can restrict other users from in seeing my files with the shared folder. Basically if I post a file from my login to the shared folder others shouldn't be able to see it and vice versa.

I tried nx5000 user's suggestion but then everyone can see all files posted in the shared folder.

A shared dir means what it says; anyone who can get into it can see all files therein.
You can use the Sticky Bit to stop others deleting your files (root excepted of course).
https://en.wikipedia.org/wiki/Sticky_bit

I am using vsftpd application on my servers. I have a user defined home folder in the server to which I upload all my logs. A software called Sterling B2B then picks up the files from there and create reports using those logs. Now that the logs are going to be uploaded by multiple users I would continue to create more user accounts and each of them would upload their logs. However the Sterling can only focus on one path. To resolve this I created a dynamic link within a folder which is now set as home directory for every user. The dynamic link is now pointing to a shared folder and sterling is supposed to pick up the files from there shared folder to execute.

Current status :
I can use SFTP to connect to server using filezilla and then rest of the plan works just fine . But this doesn't work while I use FTPES My client require SSL security and he want ftpes to be used to login. When I am logged in using ftpes I can login using filezilla and the symbolic links are listed correctly but i cannot open them due to following error message.


Below are the logs from filezilla. INBOUND is the symbolic link in below filezilla log which I am using to upload my worklog.

Status: Resolving address of ftp.xxx.xxx
Status: Connecting to xxx.xxx.xxx.xxx:xx...
Status: Connection established, waiting for welcome message...
Response: 220 (vsFTPd 2.2.2)
Command: AUTH TLS
Response: 234 Proceed with negotiation.
Status: Initializing TLS...
Status: Verifying certificate...
Command: USER vbkin
Status: TLS/SSL connection established.
Response: 331 Please specify the password.
Command: PASS ********
Response: 230 Login successful.
Command: OPTS UTF8 ON
Response: 200 Always in UTF8 mode.
Command: PBSZ 0
Response: 200 PBSZ set to 0.
Command: PROT P
Response: 200 PROT now Private.
Status: Connected
Status: Retrieving directory listing...
Command: PWD
Response: 257 "/"
Status: Directory listing successful
Status: Retrieving directory listing...
Command: CWD INBOUND
Response: 550 Failed to change directory.
Error: Failed to retrieve directory listing
Status: Resolving address of ftp.xxx.xxx
Status: Connecting to xxx.xxx.xxx.xxx:xx...
Status: Connection established, waiting for welcome message...
Response: 220 (vsFTPd 2.2.2)
Command: AUTH TLS
Response: 234 Proceed with negotiation.
Status: Initializing TLS...
Status: Verifying certificate...
Command: USER vbkin
Status: TLS/SSL connection established.
Response: 331 Please specify the password.
Command: PASS ********
Response: 230 Login successful.
Command: OPTS UTF8 ON
Response: 200 Always in UTF8 mode.
Command: PBSZ 0
Response: 200 PBSZ set to 0.
Command: PROT P
Response: 200 PROT now Private.
Status: Connected
Status: Starting download of /INBOUND
Command: CWD /
Response: 250 Directory successfully changed.
Error: Failed to open "\INBOUND" for writing
Error: File transfer failed
Status: Starting download of /INBOUND
Error: Failed to open "\INBOUND" for writing
Error: File transfer failed
Status: Starting download of /INBOUND
Error: Failed to open "\INBOUND" for writing
Error: File transfer failed

Does your client realize SFTP is at least as secure as FTP+SSL; they both rely on the same underlying libraries
Filezilla can handle sftp.
There's even scp with ssh-keys, which enables automation if required.

It almost looks like your link may have a bad name: \INBOUND... I see that:

"Status: Starting download of /INBOUND" is valid... but that would imply that \INBOUND is not, which leads me to think that perhaps the directory spec is wrong.