I'm having some issues with my FTP server that seemed to have cropped up out of nowhere. Things were working fine last week when the problems started. I think it's a permissions issue, but there are some complicating factors. This has run for several years without issue, and I can't think of anything that I did that may have broken it.
I have in excess of a dozen IP cameras across my home and two remote sites that save still images at various intervals to a common folder on my ClearOS system at home. The cameras (particularly the remote ones) use the FQDN for my system and log in with their unique usernames and passwords. This process is not broken and continues to work. I use a script on a Windows workstation to regularly log into the FTP directory on my ClearOS box and pull all of the image files (mget *.jpg then mdelete *.jpg). It then runs another script to rename them to a more human-readable file name and moves them to a directory for me to review. It's this second process that's - at least partially - not working.
The cameras on my LAN (the ones at home) dump stills into the common FTP directory and are then grabbed by the Win10 machine's script and renamed and moved. The remote cameras are also saving to the common directory, but the Win10 machine can't see those files with its log in. I can't even see them as the root user if I log into ClearOS via SSH and search that directory. If I fire up FileZilla on the Win10 machine and log into the FTP server with the private LAN IP address, all I can see are the pictures from the on-site cameras. If I re-launch and log into the same sever using the FQDN and the remote camera's username and password, I can see all of the images that that particular camera has deposited in the last week. ...and only those files from that camera. If I want to see files from another camera, I have to log out and back using the next camera's credentials.
So, possibly two issues that are stumping me:
1) Why does the address make a difference? If I'm at home shouldn't the FQDN and private LAN IP point to the same folder? Why do I have to use the FQDN to see the files?
2) My Win10 machine used to be able to see all of the files that were in the common folder. A high-privileged user of the in-box, if you will. Why can it only see files saved by devices on the local network? How do I restore the previous "all seeing" functionality to that user?
Thanks,
Bill
I have in excess of a dozen IP cameras across my home and two remote sites that save still images at various intervals to a common folder on my ClearOS system at home. The cameras (particularly the remote ones) use the FQDN for my system and log in with their unique usernames and passwords. This process is not broken and continues to work. I use a script on a Windows workstation to regularly log into the FTP directory on my ClearOS box and pull all of the image files (mget *.jpg then mdelete *.jpg). It then runs another script to rename them to a more human-readable file name and moves them to a directory for me to review. It's this second process that's - at least partially - not working.
The cameras on my LAN (the ones at home) dump stills into the common FTP directory and are then grabbed by the Win10 machine's script and renamed and moved. The remote cameras are also saving to the common directory, but the Win10 machine can't see those files with its log in. I can't even see them as the root user if I log into ClearOS via SSH and search that directory. If I fire up FileZilla on the Win10 machine and log into the FTP server with the private LAN IP address, all I can see are the pictures from the on-site cameras. If I re-launch and log into the same sever using the FQDN and the remote camera's username and password, I can see all of the images that that particular camera has deposited in the last week. ...and only those files from that camera. If I want to see files from another camera, I have to log out and back using the next camera's credentials.
So, possibly two issues that are stumping me:
1) Why does the address make a difference? If I'm at home shouldn't the FQDN and private LAN IP point to the same folder? Why do I have to use the FQDN to see the files?
2) My Win10 machine used to be able to see all of the files that were in the common folder. A high-privileged user of the in-box, if you will. Why can it only see files saved by devices on the local network? How do I restore the previous "all seeing" functionality to that user?
Thanks,
Bill
In FTP Server
Share this post:
Responses (2)
-
Accepted Answer
Thanks much!
The ClearOS box is my router, firewall, gateway, DHCP server, FTP server, etc. I had the DNS entry in there already to point the FQDN to the LAN IP, and every camera and PC was a member of the 'IP cameras' group. I'm using flexhares as you outlined.
I think I have it working again. I assigned a different user group (just a nonsense one) to the cameras share, then re-assigned the IP Cameras group. This seems to have fixed the issue as now the Win10 workstation can see all of the files in the common folder: they're not restricted to the 'user' that wrote the file. I still don't know why I couldn't see them even as the root user when I went to /var/flexshare/shares/cameras.
This is the second or third weird issue that I've had with my system in the last month. What was working fine suddenly stops then after poking around for a bit it starts working again. Maybe a reboot is in order. -
Accepted Answer
1) That only works if you set up the DNS Server with the DDNS FQDN pointing to the ClearOS LAN IP. It is not automatic.
2) Are you using flexshares on FTP port 21 for your "common directory"? If so, permissions should work by group membership and the files should be under /var/flexshare/shares. If you are not using flexshares, how are you doing it? Or are you using port 2121? In that case the files will go under all the users folders in /home. Can you check where all your files are going?
FTP is not NAT friendly and FTP to port 2121 behind NAT will probably not work if ClearOS is not your gateway device.
Please login to post a reply
You will need to be logged in to be able to post a reply. Login using the form on the right or register an account if you are new here.
Register Here »