Files locked on shared drive

It seems there have been a few posts on this topic, but no remedy that I can find.

I recently set up samba on a fbsd box as my file server and downloaded to it. I can access the images just fine from a windows browser but not from ZoomBrowser. In ZoomBrowser they are locked and the protect selection under "file" is selected however grayed out. can you offer any assistance in determining the issue? This issue also is exhibited on a windows (native CIFS) share.

Its possible its a permissions issue and when you're accessing them via windows, you're accessing them as yourself. When you're accessing them under ZoomBrowser, it might be using a service/application ID.

I had thought of that, however I can not find the service that the zoombrowser would use to start up. Do you know how I might alter who the application runs as? As this is XPhome all the files shows as my ownership. Opps, I found it. I changed the login account to my login stopped and started the service and it did not help. Do I need to re-index?

Hold down the shift key when you right click the application and then "Run as". Sounds like a permissions problem - you can do an ls -l image.jpg to see what the permissions are. I haven't used FreeBSD in ages but that sounds like the problem.

First off, you need to get an understanding of your credentials.

1. You have user credentials on your workstation.
2. You have user credentials in Samba.
3. You have user credentials in FreeBSD.

1, 2, and 3 may or may not have the same username and or password.

For ease of use, the username for 1, 2, and 3 should be the same (and not be, on the FreeBSD server, the root user or have a default group of root, admin, or wheel).

Make sure all files in the shared Samba volume that is being mounted on the XP workstation have ownership of your user and have read/write for your user.

Using "Run As" in XP isn't going to make a difference. You can "Run As" the local administrator account in XP, and it won't override the FreeBSD ACLs or the Samba ACLs (unless for some reason, the local administrator username on your XP workstation is valid on the FreeBSD server and Samba service).

The simplest way to get going:

Assuming your XP workstation username is 'bob' with password 'canon', make sure you have an account on the FreeBSD server (/etc/passwd, /etc/shadow) with the username 'bob' and password 'canon'. Create the Samba user with username 'bob' and password 'canon'. Make sure the shared directory (mapped via Samba) is owned by user 'bob'.

Hopefully you have a stronger password than 'canon'.

Unfortunately I set up environments like this for a living and have been working with Samba since about 99. I do appreciate the advice I always find a bit of wisdom in all of it. I have however found out that I have the same issue from one XP box to another XP box, it seems that ZoomBrowser does not like the share, is it because it requires and NTFS and not a CIFS file system?. I also have a Sony digital vidio camera and it's software is exibitiang the same behavour. Even if I allow full access the the share so anyone can access - read not securty - the files are still locked.

Is everyone out of ideas? Just another interesting tidbit, I am able to download pictures from my camera using the EOS utility so writing and utilizing shared disk with that app is fine, the issue is with Zoombrowser. The problem is not unique to the samba share but also present on a windows native share.

exp_02 wrote in post #7884758
Is everyone out of ideas? Just another interesting tidbit, I am able to download pictures from my camera using the EOS utility so writing and utilizing shared disk with that app is fine, the issue is with Zoombrowser. The problem is not unique to the samba share but also present on a windows native share.

I've thought on your problem and didn't come up with a few things to try if you are willing. I have a four networks hooked up in my office to test updates and check deploy changes before going live. On one of these networks I have FreeNAS, a Linux Box and at least one Windows machine from 2000 up. I can test the ZoomBrowser after work on Monday if you like to see what happens, but like I said, I have a couple of ideas.

It's been a long time since using ZoomBrowser so forgive me if I cannot answer some of your questions directly. My first thought was permissions. I remember it creates files as it looks into directories - what happens if it cannot create them? Will the files stay locked. That said, some programs - particularly those with databased dependencies - require a bit of 'networking' knowledge to function (MySQL & Oracle). Soooo, the first two idea's can be solved in one go. Start fresh with ZB in an empty NAS (share) directory and try to import files via the ZB, but make sure to un-share all other NAS folders. Mind you, you have to remove absolutly every file associated with the ZB (databases and all files). Starting fresh try to import to the new folder and see if ZB can create these new files in this fresh (share) folder. If it can then the solution is starting with fresh files with no older ZB files in the new folder. If it cannot create files, and all rights have been given properly, then ZB is the limiter. Either the internal database cannot address files across a share (not networkable) or there is a more serious problem with permissions/ownership.

I can test Monday if you like if this still doesn't help.

Interesting, I have tried most of that up and until the re-installing ZB. I aslo had freenas setup but tore it down infavor of FBSD because of zfs and the need for anothe system with a browser. ( I may go back to OpenSolaris). I have opened the permissions to 777 and allowed anonymous read/writes to the file system. I have also changed the service to start up as a user instead of system. It will take me another week to test, I am in the middle of fixing another box for a friend. I am leaning towards the application is not networkable which is to bad because it is difficult to justify a raid system on a desktop.

Thanks for the tips.