Unable to access files/folders moved to share root thru CIFS
I'm having a permissions issue that appears to only be affecting CIFS.
When I create a new file/folder within the root of a share or copy a file/folder from my desktop to the root of a share; I can access it as one would expect too.
However, If I move an existing file/folder that is located within folder on the share to the root of the same share; I lose the ability to access it through CIFS. When I attempt to access it, I receive the message below.
Network Error Windows Cannot Access \\NAS-xx-xx-xx\share_name\folder_name You do not have permission to access \\NAS-xx-xx-xx\share_name\folder_name. Contact your network administrator.
However, I can still access these files/folders using FTP/S or HTTP/S.
This occurs with new files/folders or pre-existing data already residing on the share. In other words, if I create a new folder named 'folder_1' in the root and then create a new folder named 'folder_2' and a new file named 'testfile.txt' within 'folder_1' and then move them to the share root, I'll no longer be able to access them using CIFS. I'll still be able to access and fully manipluate them using ftp/s and http/s though.
Checking and then appling the 'Set ownership and permissions for existing files and folder...' on the Share's Advance Options tab restores my ability to access them through CIFS. However, this doesn't fix the problem as the next time I move a file/folder to the share root, my access to it using CIFS is once again lost.
After encountering this, I installed the EnableRootSSH add-on to see what is happening.
If I create the following structure through cifs and ssh in; the ls cmd reports (note I can access everything here):
After moving 'folder_2' and 'testfile.txt' to the root of the share using CIFS, ls shows the following (Can no longer access folder_2 or testfile.txt) \shared\ .......|-\folder_1 .......|-\folder_2 .......|-\testfile.txt
My System Info NAS: ReadyNAS Pro Business Edition, RNDP6000-100NAS with RAIDiator 4.2.19 Clients: Windows 7 Ultimate SP1 x64
My Accounts and Groups: I have 5 user accounts and 2 groups ('users' and 'powerusers'). Two of the accounts are members of the 'powerusers' group. These accounts are also secondary members of the 'users' group. The other three accounts are members of the 'users' group only.
Shares: I have 7 shares (not including home shares). All of shares including the home shares are experiencing this issue.
Each of the shares is configured identically except for the group defined for each.
all of the shares are configured for CIFS, AFP, FTP/S, and HTTP/S.
My CIFS share configuration is: Default Access:...............Disabled Read-Only Users:.............Un-checked Write-Enabled Users:........Checked (User field is empty; group field is set to either 'users' or 'powerusers') Allow guest access:..........Un-checked Share Display Option: .......Un-checked Recycle Bin:...................Un-checked Automatically set Permissions on new files and folders:..........Checked Do not allow ACL changes to be more restrictive than this:......Checked Folder Group Rights:.........Read/Write Folder Everyone Rights:.....Read/Write File Group Rights:............Read/Write File Everyone Rights:........Read/Write Opportunistic Locking:.......Un-checked
Advanced Options Share folder Owner:...............admin share folder group:................users or powerusers (depending upon the share) Share folder owner rights:........Read/Write Share folder group rights:........Read/Write Share folder everyone rights:....Read/Write Grant rename and delete privileges to no-owner of files:...........Checked Advance Share Utilities- Shift share content timestamps by:.......0 minutes Set ownership and permissions for existing files and folder:.......Checked and applied
Re: Unable to access files/folders moved to share root thru
Bump.
I edited the post above to update the reported ls info.
I still don’t understand why this is happening. Looking at the permissions using ls, it appears to me that they are correct and that I should still be able to access the files/folders after they’ve been moved to the root of the share (I can still access them through ftp/s and http/s).
If I view the permissions from the Windows Explorer security tab before the move, it lists the following groups and users as having permissions:
Everyone CREATOR OWNER CREATOR GROUP Powerusers (NAS-EA-45-13\powerusers) tom @ xxxxx.xxx (NAS-EA-45-13\tom)
After the move, the security tab shows the following for folder_2 and testfile.txt:
"No groups or users have permission to access this object. However, the owner of this object can assign permissions"
Prior to my noticing this issue, I applied the itunes server patch (1.03) and updated squeezecenter to the full version (v7.7.0).
Re: Unable to access files/folders moved to share root thru
I just tested this using a borrowed Windows XP SP3 system and didn't encounter the problem.
My PCs (2) and Laptops (5) are all running Windows 7 Ultimate SP1 x64. All of them experience this issue.
I don't know when this problem began for me. Besides the iTunes server and squeezecenter updates, I also updated the fw of my nas to v4.2.19 sometime in the past week or two.
I am in the process of setting up a second RNDP6000 that I just purchased (plan to replicate). Its running fw 4.2.15. I'll report back as to whether or not I experience the issue with this nas and fw version.
Re: Unable to access files/folders moved to share root thru
Well, I just finished setting up my second rndp-6000-100nas nas. I configured it identically like my other one (shares, users, groups, etc) except for the difference described below.
Everything appears to be working with this NAS. I can move files and folders to the share root and still access them. It appears that either one of the add-ons or the 4.2.19 firmware update is responsible for this.
Is anyone else having this same issue? Any suggestions on how to resolve this?
The following are the differences between the two devices:
RNDP6000 with Windows 7 x64 CIFS Issue FW: v4.2.19 ReadyDNLA: enabled (v1.0.18.2) Squeezecenter: enabled (full version v7.7.0-i386-readynas installed) iTunes Server: enabled (v1.0.3) ReadyNAS Photos II: enabled (v1.0.5) ReadyNAS Remote: enabled (v1.0.9.78 shown in 'Installed' under the 'Add-ons' tab) SSH enabled: yes (installed add-on after encountering this problem) squeezeboxserver user account (created by the full squeezecenter installer)
New RNDP6000 without Windows 7 x64 CIFS Issue FW: v4.2.15 ReadyDNLA: not enabled v1.0.18.2 Squeezecenter: not enabled v7.3.2.0 iTunes Server: not enabled v1.0.0 ReadyNAS Photos II: not installed ReadyNAS Remote: not enabled (v1.0.9.30 shown in 'Installed Add-ons' under the 'Services' tab) SSH enabled: no
Re: Unable to access files/folders moved to share root thru
Based on preliminary testing, I believe that NetGear L3 support has solved my problem via a CIFS service patch that has been incorporated into beta FW 4.2.20-T19. L3 Support remoted into my NAS and updated the FW .20-T19 and the problem now appears to have been corrected.
I plan to fully test and monitor my ReadyNAS Pro that was having this issue over next few days to fully confirm that the problem has been resolved. Once my confidence is regained, I plan to update my second RNDP6000 Pro from FW 4.2.15 to FW 4.2.20-T19 and verifiy its functionaility.
I'll post an update regarding this in a few days.
NOTE: When I spoke with L3 support, they recommeded that when upgrading from FW 4.2.15, you should first update to FW 4.2.16 and then to FW 4.2.19+. This was in part due to automatic changes that are made in the partition format by FW 4.2.16. Its also important to note that you cannot downgrade back to FW 4.2.15 after updating due to these same changes. I plan to follow this advice when upgrading my second ReadyNAS Pro from FW 4.2.15 to FW 4.2.20-T19. I didn't do this when I upgraded my first ReadyNAS Pro from FW 4.2.15 to FW 4.2.19 (Although skipping FW 4.2.16 didn't cause my problem).
Re: Unable to access files/folders moved to share root thru
Thanks for posting your solution.
Good point about going to 4.2.16 first. In fact if you do an update via System > Update > Remote, if you're on firmware newer than 4.2.9 but older than 4.2.16 you'll be prompted to update to 4.2.16. When updating firmware it's a good idea to look at what the recommended update is under System > Update > Remote.
Re: Unable to access files/folders moved to share root thru
When I ran the update through Frontview, I didn't receive a prompt to update to FW 4.2.16 first.
I was running FW 4.2.15 and when I clicked the Perform System update button in Frontview it took me straight to FW 4.2.19. However, the update process did advise me that I would not be able to roll back to FW 4.2.15 after performing the update. Maybe this has changed since I did the update or something went wrong for me.
It would definitely be a good thing if Frontview did what you described. Either way, from now on, I don't plan to jump past any FW versions that contain significant changes that prevent you from rolling back to a prior version.
I was also advised my L3 that I should set the share folder owner and group on the advanced options tab to admin admin. This is their current recommended default setting for user mode. Unfortunately, it doesn’t automatically get set this when creating a new share. New shares are still set to nobody/nogroup which is a carryover from share mode that has been phased out.
I’ve been setting my share folder user to admin and group to the primary user group that I had created the share for based on my understanding gleaned from articles written by other here. I’ve now changed this to the L3 recommendation of admin/admin.
Re: Unable to access files/folders moved to share root thru
After more extensive testing, I can report that the CIFS service patch that was incorporated into beta FW 4.2.20-T19 fixed my problem.
I can also report that same problem that I had on my first ReadyNAS Pro was introduced into my second ReadyNAS Pro when I updated its FW from 4.2.15 to FW 4.2.16. Updating the FW on this NAS to 4.2.20-T19 resolved the issue on this NAS too.
Apparently the problem I was experiencing was introduced in FW 4.2.16 and carried forward through all subsequent versions until 4.2.20-T19.
Since 4.2.20-T19 is beta, hopefully it won't be broken and the problem reintroduced in the future beta or final version.
A big thank you to the L3 support team for investigating and correcting my issue.
