That should be: "Unable to modify shared files and folders."

I am running Active Directory on a Windows Server 2003 Standard (SP2) machine. I added an external hard drive to hold shared files. I didn't have an problem moving the files from their original location on the server's internal HDD. However, I am no longer able to modify the files or folders from any machine except the server itself. The Windows Vista message I receive when trying to create a new folder is "You need permission to perform this action." I can view and open files but they open read-only. When trying to save changes or create a new file, the message is "You don't have permssion to save in this location."

I set the file permissions to full control for all users. That made no difference. I set the file permissions to full control for an individual user. Using that account from a client system made no difference. I logged onto a client with an admin account; that made no difference. I logged onto a client with the admin account and even that did not make a difference. (However, if I'm at the server itself, it works.) I checked effective permissions and it shows full control (all boxes checked). There are no deny settings in place at the moment for anything on the share.

The drive is a WD My Book Essential (1 TB). It has the option of password protecting the entire drive but I did not activate that. It is running drive management software (WD SmartWare).

I had connected another USB drive in the past for file sharing and had no problem with it whatsoever.

Does anyone have any idea what I should try to get this worked out? (By the way, I've already restarted both the server and the client systems.)

Dani AI

Generated

A short, practical explanation: Windows network access is governed by two layers — NTFS (Security) permissions on the folder and the Share permissions set when you share that folder. For SMB connections the effective right is the most restrictive of the two. That means a remote user can be blocked from creating or saving files even when NTFS shows Full Control. This thread is a classic example of that interplay; ’s troubleshooting path illustrates it.

What to check (quick checklist):

  • Confirm the external drive is formatted NTFS (Drive -> Properties). FAT filesystems do not support NTFS security.
  • Temporarily set the share-level permission to Everyone = Full Control (Sharing tab or Computer Management -> Shared Folders -> Shares) to isolate whether the share itself is the blocker.
  • On the folder’s Security tab open Advanced -> Effective Permissions (or Effective Access on newer OSes) and test with the actual domain/user account you use from the client.
  • Check Ownership and Inheritance (Advanced -> Owner / Replace owner on subcontainers) — copying between volumes can change owner/inherited rights.
  • If vendor software (WD SmartWare or similar) is present, disable or uninstall it for testing; some vendor tools lock files or change access behavior.

Quick GUI pointers and best practice: on Server 2003 use Sharing and Security from the folder Properties to edit share perms, and use the Security -> Advanced -> Effective Permissions tool to simulate a user’s result. A safe workflow is: set share to Everyone = Full Control for testing, then use NTFS to implement the precise access model (domain groups, remove Everyone afterwards). Log and review Security/System events if access is still denied.

Keep changes documented and test from a real client account (not just an elevated server session). The share-vs-NTFS mismatch is common and easily fixed once both layers are checked.

I posted this same problem to another forum. The reply I received encouraged me to check inherited permissions and share permissions in addition to file permissions.

I checked the permissions from the top down and all of them were set correctly.

The sharing permission was set to Everyone --> Read only. I changed it to Full control but won't be able to check it until I restart the server tomorrow morning (I created a temporary problem by powering down the drive). If this is what it is (and I hope and believe that is the case), I'm going to feel like a real idiot.

I'll post an update as soon as I know something.

Adjusting the sharing permissions fixed the problem.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.