An office associate regularly updates a calendar PDF on a shared windows network drive. This calendar is referenced throughout the day by many of the 20-40 staff on the network, often leaving this file open in their Acrobat Readers for hours on end.

If the file is open anywhere, it cannot be updated by the publishing user, due to a file lock. This means a hunt around the office, and email broadcasts to close the @#$% PDF!

What user or network admin actions would you suggest so we don't need to send/receive these uncomfortable emails?

Some details: * Windows network shares, which we all have mounted as a drive letter * I believe the servers are Linux/Unix running Samba (rather than Windows server software) * Mostly XP clients, and pretty locked-down. Desktop client changes mean support visits every workstation.


  • 3
    Why in the world are you using a pdf to hold a calendar? Talk about the wrong tool for the job. – Joel Coehoorn Jul 29 '10 at 1:25
  • 1
    @Joel: I wouldn't jump the gun on this. PDFs have advantages in some office environments. Just because it was implemented wrong here doesn't mean it's a bad idea. – hotei Jul 29 '10 at 5:15

If slartibartfast's answer isn't feasible for you for some reason (like not wanting to set up your first-ever intranet web server...), consider the following.

If the file server is based on Unix/Linux/MacOSX using Samba: Create a shared network directory that is read/write for the publishing user(s). Let's name the share pdf-rw, and one of the publishing user(s) pdfpublisher. In Samba's config file smb.conf set this up like this:

  comment = Writeable for pdfpublisher(s) only (and not browseable for users)
  path = /path/on/unix/system
  browseable = no
  writeable = no
  write list = pdfpublisher, domainname\\who.ever, onemoreuser
  guest ok = no

Create another shared network directory that is readonly for everybody else. Let's name the share pdf-ro. In Samba's config file smb.conf set this up like that:

  comment = Read-only for users (as well as browseable)
  path = /path/on/unix/system
  browseable = yes
  writeable = no
  guest ok = yes
  map to guest = bad user

The trick is to define 2 different share(name)s with 2 different settings:

  • the readonly share is also browseable and even accessible for guest users without a password (and may be mapped as a network drive if you want);
  • the read/write share is hidden and does not appear in the network neighbourhood (it can be accessed if you know the \\servername\pdf_rw UNC path, plus if you know how to provide one of the named users' credentials; it may also be mapped to a network drive).

If the file server is based on Windows: Pick one of the suggestions made by other users and test if it works for you.

Big caveat:

Be aware that any update to the PDF document by the publisher will not be automatically noticed by the clients. Depending on their PDF viewer software + version, they may still see the old version of the file unless they re-load it.

| improve this answer | |

Publish the document on a web server. The editor edits it there. The readers have lockless access with a commonly available client (IE, Firefox, Chrome, Safari, etc. etc. etc.)

Oh, and I feel dirty for suggesting this, so you're welcome. :)

| improve this answer | |
  • And with Samba access the editing process would be just the same. – pelms Jul 29 '10 at 11:01

One workaround we used in my office with shared files like this that needed to be updated regularly (mostly spreadsheets) was a hidden shared folder that only the person that needs to update the file has access to. This folder has the "master" of the shared copy, and you just copy it out once its edited. If it's locked it's less of an issue since the update is done.

| improve this answer | |

Right-click, Properties > Attributes > Read only. Maybe.

| improve this answer | |
  • doesn't work in my particular case.. It's being used by another user or program (for a ms access file) – Totty.js Feb 20 '13 at 14:32

I'm assuming this is windows. You can set the permissions where the users can only read the document (read only). This might prevent the system from placing a lock on the file. If that doesn't work you can always powercycle the server which is serving the file and all locks will be lost. (logging out and back in might do it too but I wouldn't be certain).

I feel there must be a better solution still but this is all I could think of.

| improve this answer | |
  • 5
    You gotta be kidding! Power off the server just to clear a lock!!! You're so fired. – hotei Jul 29 '10 at 5:10
  • Hmm, so instead I'm going to waste the time of roughly 30 users which annoys everybody? It's not an optimal solution, and if it's on say a virtual machine by itself or whatever it could work. When I responded there were no other answers. Better than your no response. – Daisetsu Jul 29 '10 at 5:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.