Some sub-Folders on SMB/CIFS External Storage are read only. (You don't have permissions to upload or create files here.) #24608

Closed
Orbital-Bit opened this Issue May 12, 2016 · 40 comments

Projects

None yet

7 participants

@Orbital-Bit
Orbital-Bit commented May 12, 2016 edited

notes:
this happens both as user with pass-through, or as admin in admin settings.
both users have Full Control on the destination disk and share, also one user is owner of entire folder
(re-applied permissions).
both users can edit the entire share as expected with other clients - like windows explorer or ubuntu unity.
tried ./occ files:scan --all it completes, but did not help.

Steps to reproduce

  1. create new connection from OwnCloud to an existing SMB share (External Storage)
  2. when browsing SMB storage with WebUI some sub-folders are read only.
    these display "You don't have permissions to upload or create files here."
    but in these 'Read Only' folders, the sub-folders continue to work as expected.
  3. syncning with Client shows error - "not allowed because you don't have permission to add files in that folder", but can sync sub-folders of these.

Expected behavior

Folder and its contents should be changeable by user

Actual behavior

user can't edit contents of some folders, user can read contents,
user can edit sub-folders of these read only folders.
user receives;
"You don't have permissions to upload or create files here."
or
"not allowed because you don't have permission to add files in that folder"

Server configuration

Operating system:
Ubuntu 14.04
Web server:
Apache 2.4.7
Database:
MySQL 5.6
PHP version:
PHP 7
ownCloud version: (see ownCloud admin page)
9.0.2
Updated from an older ownCloud or fresh install:
update or fresh
Where did you install ownCloud from:
Ubuntu repo
Signing status (ownCloud 9.0 and above):

http://example.com/index.php/settings/integrity/failed 
No errors have been found.

List of activated apps:

Enabled:
  - activity: 2.2.1
  - agreedisclaimer: 1.0.0
  - comments: 0.2
  - dav: 0.1.6
  - documents: 0.12.0
  - external: 1.2
  - federatedfilesharing: 0.1.0
  - federation: 0.0.4
  - files: 1.4.4
  - files_external: 0.5.2
  - files_mv: 0.8.2
  - files_pdfviewer: 0.8.1
  - files_reader: 0.7.1
  - files_sharing: 0.9.1
  - files_texteditor: 2.1
  - files_trashbin: 0.8.0
  - files_versions: 1.2.0
  - files_videoplayer: 0.9.8
  - gallery: 14.5.0
  - music: 0.3.11
  - notifications: 0.2.3
  - provisioning_api: 0.4.1
  - systemtags: 0.2
  - templateeditor: 0.1
  - updatenotification: 0.1.0

The content of config/config.php:

        "instanceid": "ocxxx15",
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "trusted_domains": [
            "sync2.xxx.com",
            "sync.xxx.com"
        ],
        "datadirectory": "\/mnt\/SYNC-data\/own-data",
        "overwrite.cli.url": "https:\/\/sync2.xxx.com:4443",
        "dbtype": "mysql",
        "dbname": "OC-XXX",
        "dbhost": "127.0.0.1",
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "installed": true,
        "version": "9.0.2.2",
        "logtimezone": "America\/New_York",
        "loglevel": 0,
        "memcache.local": "\\OC\\Memcache\\Redis",
        "filelocking.enabled": "true",
        "memcache.distributed": "\\OC\\Memcache\\Redis",
        "memcache.locking": "\\OC\\Memcache\\Redis",
        "ldapIgnoreNamingRules": false,
        "appstore.experimental.enabled": true,
        "preview_libreoffice_path": "\/usr\/bin\/libreoffice",
        "knowledgebaseenabled": false,
        "check_for_working_htaccess": true,
        "check_for_working_webdav": true,
        "has_internet_connection": true,
        "filesystem_check_changes": 1,
        "theme": "",
        "maintenance": false,
        "updatechecker": false

Are you using external storage, if yes which one:
SFTP and SMB/CIFS

Are you using encryption:
no

Are you using an external user-backend, if yes which one:
no

Client configuration

Browser:
Chrome, IE, Firefox (any)
Operating system:
Windows 7-10, 2008-2012. Ubuntu.

Logs

Web server error log

[Thu May 12 04:30:54.819769 2016] [mpm_prefork:notice] [pid 1184] AH00169: caught SIGTERM, shutting down
[Thu May 12 04:35:53.727423 2016] [ssl:warn] [pid 1177] AH01909: RSA certificate configured for owncloud:4443 does NOT include an ID which matches the server name
[Thu May 12 04:35:53.757048 2016] [ssl:warn] [pid 1177] AH01909: RSA certificate configured for owncloud:443 does NOT include an ID which matches the server name
[Thu May 12 04:35:57.320939 2016] [ssl:warn] [pid 1192] AH01909: RSA certificate configured for owncloud:4443 does NOT include an ID which matches the server name
[Thu May 12 04:35:57.321322 2016] [ssl:warn] [pid 1192] AH01909: RSA certificate configured for owncloud:443 does NOT include an ID which matches the server name
[Thu May 12 04:35:57.326638 2016] [mpm_prefork:notice] [pid 1192] AH00163: Apache/2.4.7 (Ubuntu) OpenSSL/1.0.1f configured -- resuming normal operations
[Thu May 12 04:35:57.326667 2016] [core:notice] [pid 1192] AH00094: Command line: '/usr/sbin/apache2'

ownCloud log (data/owncloud.log)

{"reqId":"o2E8cO1yOX\/UbAoMgkyU","remoteAddr":"4.1.14.103","app":"OC\\Files\\Cache\\Scanner","message":"!!! Path 'Desktop\/$RECYCLE.BIN' is not accessible or present !!!","level":0,"time":"2016-05-12T14:39:15-04:00","method":"PROPFIND","url":"\/remote.php\/webdav\/Documents-SMB\/Desktop","user":"A7E378AE-43A2-47CB-9075-9F0FAE1964DB_7507"}
{"reqId":"o2E8cO1yOX\/UbAoMgkyU","remoteAddr":"4.1.14.103","app":"OC\\Files\\Cache\\Scanner","message":"!!! Path 'Desktop\/desktop.ini' is not accessible or present !!!","level":0,"time":"2016-05-12T14:39:15-04:00","method":"PROPFIND","url":"\/remote.php\/webdav\/Documents-SMB\/Desktop","user":"A7E378AE-43A2-47CB-9075-9F0FAE1964DB_7507"}
{"reqId":"o2E8cO1yOX\/UbAoMgkyU","remoteAddr":"4.1.14.103","app":"OC\\Files\\Cache\\Scanner","message":"!!! Path 'Desktop\/Thumbs.db' is not accessible or present !!!","level":0,"time":"2016-05-12T14:39:16-04:00","method":"PROPFIND","url":"\/remote.php\/webdav\/Documents-SMB\/Desktop","user":"A7E378AE-43A2-47CB-9075-9F0FAE1964DB_7507"}
{"reqId":"o2E8cO1yOX\/UbAoMgkyU","remoteAddr":"4.1.14.103","app":"OC\\Files\\Cache\\Scanner","message":"!!! Path 'Desktop\/$RECYCLE.BIN' is not accessible or present !!!","level":0,"time":"2016-05-12T14:39:16-04:00","method":"PROPFIND","url":"\/remote.php\/webdav\/Documents-SMB\/Desktop","user":"A7E378AE-43A2-47CB-9075-9F0FAE1964DB_7507"}
{"reqId":"o2E8cO1yOX\/UbAoMgkyU","remoteAddr":"4.1.14.103","app":"OC\\Files\\Cache\\Scanner","message":"!!! Path 'Desktop\/desktop.ini' is not accessible or present !!!","level":0,"time":"2016-05-12T14:39:16-04:00","method":"PROPFIND","url":"\/remote.php\/webdav\/Documents-SMB\/Desktop","user":"A7E378AE-43A2-47CB-9075-9F0FAE1964DB_7507"}
{"reqId":"o2E8cO1yOX\/UbAoMgkyU","remoteAddr":"4.1.14.103","app":"OC\\Files\\Cache\\Scanner","message":"!!! Path 'Desktop\/Thumbs.db' is not accessible or present !!!","level":0,"time":"2016-05-12T14:39:16-04:00","method":"PROPFIND","url":"\/remote.php\/webdav\/Documents-SMB\/Desktop","user":"A7E378AE-43A2-47CB-9075-9F0FAE1964DB_7507"}
{"reqId":"o2E8cO1yOX\/UbAoMgkyU","remoteAddr":"4.1.14.103","app":"OC\\Files\\Cache\\Scanner","message":"!!! Path 'Desktop\/$RECYCLE.BIN' is not accessible or present !!!","level":0,"time":"2016-05-12T14:39:16-04:00","method":"PROPFIND","url":"\/remote.php\/webdav\/Documents-SMB\/Desktop","user":"A7E378AE-43A2-47CB-9075-9F0FAE1964DB_7507"}
{"reqId":"o2E8cO1yOX\/UbAoMgkyU","remoteAddr":"4.1.14.103","app":"OC\\Files\\Cache\\Scanner","message":"!!! Path 'Desktop\/desktop.ini' is not accessible or present !!!","level":0,"time":"2016-05-12T14:39:16-04:00","method":"PROPFIND","url":"\/remote.php\/webdav\/Documents-SMB\/Desktop","user":"A7E378AE-43A2-47CB-9075-9F0FAE1964DB_7507"}
{"reqId":"o2E8cO1yOX\/UbAoMgkyU","remoteAddr":"4.1.14.103","app":"OC\\Files\\Cache\\Scanner","message":"!!! Path 'Desktop\/Thumbs.db' is not accessible or present !!!","level":0,"time":"2016-05-12T14:39:16-04:00","method":"PROPFIND","url":"\/remote.php\/webdav\/Documents-SMB\/Desktop","user":"A7E378AE-43A2-47CB-9075-9F0FAE1964DB_7507"}
{"reqId":"o2E8cO1yOX\/UbAoMgkyU","remoteAddr":"4.1.14.103","app":"OC\\Files\\Cache\\Scanner","message":"!!! Path 'Desktop\/$RECYCLE.BIN' is not accessible or present !!!","level":0,"time":"2016-05-12T14:39:16-04:00","method":"PROPFIND","url":"\/remote.php\/webdav\/Documents-SMB\/Desktop","user":"A7E378AE-43A2-47CB-9075-9F0FAE1964DB_7507"}
{"reqId":"o2E8cO1yOX\/UbAoMgkyU","remoteAddr":"4.1.14.103","app":"OC\\Files\\Cache\\Scanner","message":"!!! Path 'Desktop\/desktop.ini' is not accessible or present !!!","level":0,"time":"2016-05-12T14:39:16-04:00","method":"PROPFIND","url":"\/remote.php\/webdav\/Documents-SMB\/Desktop","user":"A7E378AE-43A2-47CB-9075-9F0FAE1964DB_7507"}
{"reqId":"o2E8cO1yOX\/UbAoMgkyU","remoteAddr":"4.1.14.103","app":"OC\\Files\\Cache\\Scanner","message":"!!! Path 'Desktop\/Thumbs.db' is not accessible or present !!!","level":0,"time":"2016-05-12T14:39:16-04:00","method":"PROPFIND","url":"\/remote.php\/webdav\/Documents-SMB\/Desktop","user":"A7E378AE-43A2-47CB-9075-9F0FAE1964DB_7507"}
{"reqId":"XcFKByAxpG+lWz9Et2zD","remoteAddr":"4.1.14.103","app":"OC\\Files\\Cache\\Scanner","message":"!!! Path 'Desktop\/$RECYCLE.BIN' is not accessible or present !!!","level":0,"time":"2016-05-12T14:39:16-04:00","method":"GET","url":"\/index.php\/apps\/files\/ajax\/getstoragestats.php?dir=%2FDocuments-SMB%2FDesktop","user":"A7E378AE-43A2-47CB-9075-9F0FAE1964DB_7507"}
{"reqId":"XcFKByAxpG+lWz9Et2zD","remoteAddr":"4.1.14.103","app":"OC\\Files\\Cache\\Scanner","message":"!!! Path 'Desktop\/desktop.ini' is not accessible or present !!!","level":0,"time":"2016-05-12T14:39:16-04:00","method":"GET","url":"\/index.php\/apps\/files\/ajax\/getstoragestats.php?dir=%2FDocuments-SMB%2FDesktop","user":"A7E378AE-43A2-47CB-9075-9F0FAE1964DB_7507"}
{"reqId":"XcFKByAxpG+lWz9Et2zD","remoteAddr":"4.1.14.103","app":"OC\\Files\\Cache\\Scanner","message":"!!! Path 'Desktop\/Thumbs.db' is not accessible or present !!!","level":0,"time":"2016-05-12T14:39:16-04:00","method":"GET","url":"\/index.php\/apps\/files\/ajax\/getstoragestats.php?dir=%2FDocuments-SMB%2FDesktop","user":"A7E378AE-43A2-47CB-9075-9F0FAE1964DB_7507"}
{"reqId":"7cj+MxzJYcZhWcZP6gbW","remoteAddr":"4.1.14.103","app":"OC\\Files\\Cache\\Scanner","message":"!!! Path 'Desktop\/$RECYCLE.BIN' is not accessible or present !!!","level":0,"time":"2016-05-12T14:39:25-04:00","method":"MOVE","url":"\/remote.php\/webdav\/Documents-SMB\/Desktop\/Prime95","user":"A7E378AE-43A2-47CB-9075-9F0FAE1964DB_7507"}
{"reqId":"7cj+MxzJYcZhWcZP6gbW","remoteAddr":"4.1.14.103","app":"OC\\Files\\Cache\\Scanner","message":"!!! Path 'Desktop\/desktop.ini' is not accessible or present !!!","level":0,"time":"2016-05-12T14:39:25-04:00","method":"MOVE","url":"\/remote.php\/webdav\/Documents-SMB\/Desktop\/Prime95","user":"A7E378AE-43A2-47CB-9075-9F0FAE1964DB_7507"}
{"reqId":"7cj+MxzJYcZhWcZP6gbW","remoteAddr":"4.1.14.103","app":"OC\\Files\\Cache\\Scanner","message":"!!! Path 'Desktop\/Thumbs.db' is not accessible or present !!!","level":0,"time":"2016-05-12T14:39:25-04:00","method":"MOVE","url":"\/remote.php\/webdav\/Documents-SMB\/Desktop\/Prime95","user":"A7E378AE-43A2-47CB-9075-9F0FAE1964DB_7507"}
{"reqId":"7cj+MxzJYcZhWcZP6gbW","remoteAddr":"4.1.14.103","app":"webdav","message":"Exception: {\"Message\":\"HTTP\\\/1.1 403 Forbidden\",\"Exception\":\"Sabre\\\\DAV\\\\Exception\\\\Forbidden\",\"Code\":0,\"Trace\":\"#0 \\\/var\\\/www\\\/owncloud\\\/3rdparty\\\/sabre\\\/dav\\\/lib\\\/DAV\\\/CorePlugin.php(640): OCA\\\\DAV\\\\Connector\\\\Sabre\\\\ObjectTree->move('Documents-SMB\\\/D...', 'Documents-SMB\\\/D...')\\n#1 [internal function]: Sabre\\\\DAV\\\\CorePlugin->httpMove(Object(Sabre\\\\HTTP\\\\Request), Object(Sabre\\\\HTTP\\\\Response))\\n#2 \\\/var\\\/www\\\/owncloud\\\/3rdparty\\\/sabre\\\/event\\\/lib\\\/EventEmitterTrait.php(105): call_user_func_array(Array, Array)\\n#3 \\\/var\\\/www\\\/owncloud\\\/3rdparty\\\/sabre\\\/dav\\\/lib\\\/DAV\\\/Server.php(459): Sabre\\\\Event\\\\EventEmitter->emit('method:MOVE', Array)\\n#4 \\\/var\\\/www\\\/owncloud\\\/3rdparty\\\/sabre\\\/dav\\\/lib\\\/DAV\\\/Server.php(248): Sabre\\\\DAV\\\\Server->invokeMethod(Object(Sabre\\\\HTTP\\\\Request), Object(Sabre\\\\HTTP\\\\Response))\\n#5 \\\/var\\\/www\\\/owncloud\\\/apps\\\/dav\\\/appinfo\\\/v1\\\/webdav.php(55): Sabre\\\\DAV\\\\Server->exec()\\n#6 \\\/var\\\/www\\\/owncloud\\\/remote.php(138): require_once('\\\/var\\\/www\\\/ownclo...')\\n#7 {main}\",\"File\":\"\\\/var\\\/www\\\/owncloud\\\/apps\\\/dav\\\/lib\\\/connector\\\/sabre\\\/objecttree.php\",\"Line\":218,\"User\":\"A7E378AE-43A2-47CB-9075-9F0FAE1964DB_7507\"}","level":0,"time":"2016-05-12T14:39:25-04:00","method":"MOVE","url":"\/remote.php\/webdav\/Documents-SMB\/Desktop\/Prime95","user":"A7E378AE-43A2-47CB-9075-9F0FAE1964DB_7507"}

image

image

image

image

thank you for your time everyone

@PVince81
Collaborator

Does the folder in question have read-only permissions ? There's this thing about Windows ignoring read-only permissions on folders, so people might expect that ownCloud behaves like Windows does.

@Orbital-Bit
Orbital-Bit commented May 13, 2016 edited

I've double checked the NTFS permissions, and reset them recursively to Full Control.
I also checked and reset Inheritance settings on those problem folders. Problem was not resolved.

@alankeny

I noticed this on our server a few days after I upgraded to 9.0.2. It was working OK on OwnCloud 9.0.1.

We have a SAMBA share called home which contains a folder for each user. I create an SMB/CIFS external storage connection in each account with a share name of home and a remote sub-folder of the account name. After upgrading to 9.0.2 the root of this external storage in every user's account shows the message "You don't have permission to upload or create files here".

Mapped drives to these folders on Windows clients are still read/write. An older web interface called WebDAV.cgi that uses smbclient still offers read/write access that works. Only OwnCloud 9.0.2 shows these folders as read-only.

OwnCloud 9.0.2 shows the sub-folders of these folders as read/write. I can also edit the contents of files in these read-only folders. I just can't upload new files or delete existing files. Uploading a file through OwnCloud via WebDAV gives a 403 forbidden error.

@PVince81
Collaborator

Hmmm, if it worked in 9.0.1 then this is a regression.
@Orbital-Bit do you remember whether it worked correctly for you in 9.0.1 (if you ever had that version).

@Orbital-Bit
Orbital-Bit commented May 17, 2016 edited

@PVince81
we went from 8.2.4 to 9.0.2.
On OC 8 we had only one SMB External Storage connected, that share worked fine and that share still works fine.
we noticed the problem when we added more shares to OC 9. only some of the newly added shares mis-behave in the manner described.

@alankeny

This is turning into a real problem for me. Can I downgrade from OwnCloud 9.0.2 to 9.0.1 safely?

I've double-checked the permissions on these folders on the Samba server. They are identical for each user. Each user has been assigned full control on their home folder. No permissions are assigned to sub-folders. The sub-folders only show the inherited permissions from the user's home folder.

Several users have working home folders in OwnCloud. The hidden permissions variable is 15 on their home folder and all of their sub-folders. As far as I can tell this number matches the full control permissions they have on the Windows share.

Most users have restricted permissions showing in OwnCloud, even though they have the same Windows permissions as the users whose home folders work correctly. The home folder itself shows permissions = 9. The first and second level folders under their home folder show permissions = 7. If they have a deeper folder structure than that, the folders show permissions = 15.

If I can't downgrade to 9.0.1 safely, is there an easy way I force permissions = 15 in OwnCloud? None of the shares I have setup in OwnCloud are read-only. If a user can access the share, they have read/write permissions to it, so the permissions set to 7 and 9 should never apply.

@PVince81
Collaborator

The part I find weird is that some of you say that 9.0.1 worked fine but 9.0.2 didn't, which means there's a regression.

@icewind1991 @jvillafanez can you help ?

@PVince81 PVince81 added this to the 9.0.3-current-maintenance milestone May 30, 2016
@jvillafanez
Contributor

We're using the 'DOS' permissions or the file attributes (not really sure what's the "official" name), basically whether the file is read-only or hidden.

@Orbital-Bit by your comments, I think you're using windows ACLs, which is a different mechanism.

In order to check the DOS permissions, you can open a windows console (in windows) and check file attributes with the "attrib" command, something like:

attrib C:\Your\path\to\file.txt

You can remove the read-only attribute using the following command (in windows - adapt the file name to your needs):

attrib -r C:\Your\path\to\file.txt

You can check more info in https://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/attrib.mspx?mfr=true (it's for XP, but I don't think there are changes between versions regarding this topic)

@alankeny
alankeny commented Jun 5, 2016

I thought I was only using Windows ACLs on my Samba server. It turns out several directories had the DOS read-only attribute on them as well. I could only find them and change them from a Windows command prompt.

A recent change to OwnCloud seems to have started tracking the DOS attributes on files and directories, even though my Samba server seems to ignore the read-only attribute on directories. I tracked the relevant change back to apps/files_external/lib/smb.php and the addition of isReadable and isUpdatable between 9.0.0 and 9.0.1.

I recursively removed all of the read-only attributes from files and directories on my home share using the attrib command. That seems to have cleared up the problem for me, although I still don't understand how the read-only attribute is supposed to work with directories on Windows shares.

@fiskn
fiskn commented Jun 7, 2016

I've been hit with this as well over the last couple of weeks, it was only the last comment which pointed me in the right direction to fix it. In my case, none of my files were marked read only. However there were some hidden+system files (thumbs.db, desktop.ini) which seem to be causing a similar problem. These files were stopping me uploading new files to the whole of the folder.

After deleting these files, everything started working as expected.

@PVince81
Collaborator

@jvillafanez @icewind1991 is there anything that should be done on the OC side here ?

@jvillafanez
Contributor

When we try to detect the changes in the backend, we could add the current (stored) permissions into the mix to decide whether the file / folder has changed. However this will very likely have performance implications. I think we need to check what storages can handle the extra load (if any) before starting.

@Orbital-Bit
Orbital-Bit commented Jun 14, 2016 edited

@fiskn this was exactly the issue. Removing read-only attribute from those files resolves the issue.

@OCDevs These are pretty standard files in the windows world, and if they are read-only (or any single file in a directory) this should not trip up OwnCloud and turn the directory read-only.

thank you for your time.

@PVince81
Collaborator

These are pretty standard files in the windows world, and if they are read-only (or any single file in a directory) this should not trip up OwnCloud and turn the directory read-only.

@icewind1991 @jvillafanez hmm, why would the SMB code misinterpret permissions as read-only when only a single file inside a folder has read-only permissions ?

If the folder itself has read-only permissions, then is understandable that ownCloud considers it as read-only too.

@alankeny

If the folder itself has read-only permissions, then is understandable that ownCloud considers it as read-only too.

According to this KB https://support.microsoft.com/en-us/kb/326549 under the CAUSE section, the read-only attribute on a Windows folder does not mean that it should be considered read-only. To Windows it means that the folder had its view customized by Windows.

While I fixed my problem using the attrib command earlier, I actually shouldn't have. Removing the read-only attribute from those folders removed view customization my users set on them.

@PVince81
Collaborator

Argh... Ok, so I guess this means ownCloud and/or the SMB library should then ignore read-only permissions on folders.

@jvillafanez
Contributor

According to this KB https://support.microsoft.com/en-us/kb/326549 under the CAUSE section, the read-only attribute on a Windows folder does not mean that it should be considered read-only. To Windows it means that the folder had its view customized by Windows.

:trollface: Windows... :trollface:

Has anyone tried the behaviour in other OS? I think samba (in linux) behaves properly, and I'm not sure about MacOS (I had issues with the signature and I couldn't try).

@Orbital-Bit
Orbital-Bit commented Jun 17, 2016 edited

@jvillafanez
i can confirm that modifying the view on a folder causes the issue in OwnCloud.
(these settings are saved to a hidden file 'desktop.ini', and this file and the the directory Attributes are set to Read-Only.)
and as previously confirmed using the command line to remove this setting from the folder resolves the issue.
also can confirm that the folders work as expected in Ubuntu, Android and OS X (or is it MacOS now?)

so this issue is about a directory Attribute, not file or directory Security Permissions.
Attributes and Permissions are separate settings a file and/or a directory can have.
Read-Only Attribute should be ignored on directories (as apparently it was in version 9.0.1 and earlier).

thank you @alankeny @jvillafanez @fiskn

@alankeny

I mentioned earlier that I worked around this problem by removing the read-only attribute on the directories on my Samba server. For the most part that fixed the problem. A few users still can't see some of the folders that had been marked with the read-only attribute. Other users can see the folders even though they're on the same share.

I've tried using files:scan, but I can only get it to scan local files. I've tried:
occ files:scan --path username/files
and
occ files:scan --all

Since some users can see the folder and others can't, I assume this has to be related to some kind of caching for external storage. How can I force OwnCloud to refresh the folder contents of external storage for the users that are having problems?

@jvillafanez
Contributor

@alankeny could you try to do a files:scan inside the mount? It might ignore the mounts by default due to performance reasons. If that doesn't work, you could "touch" the affected folder, or create / delete a file inside them in the backend

@htwsaaraub
htwsaaraub commented Jun 20, 2016 edited

We have severall SMB Directories which are auto mounted at the user login.
All this Folders work very well, all users are able to upload files, exept the Home Directory with Special Folders in it.

In Windows I moved my Desktop and my Documents folder to a SMB-Share, which is mounted as Home Directory in Owncloud. When setting this, windows set these folders as system-folders with a system.ini and add a Read-Only Attribute to it. In my Case these special Directories and the Root of the Share are read-only in owncloud.

If I create a new folder in my Home Directory via Windows, which is a none-system Folder, Owncloud is able to Upload Files to this Folder.
I am also able to Upload File to the subdirectories of the Desktop Folder.

When I remove the Read-Only attribute from the Folder this folder Owncloud immetiately let me upload Files to this Folder.

attrib -R Desktop
attrib -R Documents

I testet some Subfolders of the Desktop Folder. If I set the Read-Only attrib for the Subfolder owncloud stops me from Uploading Files to this folder.
When I revert the Read-Only Attribute with a attrib -R owncloud is immeditately able to Upload Files to this Folder.

So Owncloud have to ignore this attrib setting. It's not caused by Desktop.ini or another sytem-file.
This behaviour is only since Owncloud 9.02. In 9.01 this worked as expected.

So what are the code changes in this version causing this behaviour?
@icewind1991 Can you have a look at it?

Client-OS: Windows 10
Server-OS: Windows Server 2008, 32bit (Fileserver)
Owncloud: 9.02
@alankeny

@alankeny could you try to do a files:scan inside the mount? It might ignore the mounts by default due to performance reasons. If that doesn't work, you could "touch" the affected folder, or create / delete a file inside them in the backend

@jvillafanez I've tried doing a files:scan on the mount point and on the affected folder inside the mount point that isn't visible. Any attempts to files:scan on an SMB share mount return 0 files.

I've also tried touching the mount point, touching the affected folder inside the mount point that isn't visible, creating a file inside the mount point, and creating a file in the affected folder inside the mount point that isn't visible. None of these actions have made the folder visible for the users that can't see it. These users have permission to access the folder, because they can view the folder's contents by specifying the folder path manually in the browser's URL.

Please let me know which flags I should use on files:scan to get OwnCloud to scan SMB shares on external storage.

@PVince81
Collaborator

Please let me know which flags I should use on files:scan to get OwnCloud to scan SMB shares on external storage.

occ files:scan --all usually already goes into SMB shares.
You might want to narrow it down by specifying a user id instead of "--all"

@jvillafanez
Contributor

In addition, check with smbclient what permission does the server send to the client (adjust whatever is needed):

smbclient -U '[user]%[password]' -c 'dir path/to/folder/*' '//server/share'
@alankeny

It finally occurred to me that files:scan will never work with my SMB shares, because I'm using the "Log-in credentials, save in session" option on them. occ files:scan doesn't have access to the contents of the share, because it doesn't have access to the share's password. That left me with a different problem.

After specific folders were skipped for some of my users because of the folder attributes, OwnCloud never checked them again, even after I changed the attributes. I had to access the database directly and run delete from oc_filecache where storage = 11; 11 is the numeric_id of the user's external storage in the oc_storages table that was having the problem with missing folders. After I deleted the rows from the oc_filecache table, OwnCloud started showing the full folder contents correctly.

After looking through the other occ commands, it doesn't look like occ can purge cache data for external storage when the "Log-in credentials, save in session" option is used. There doesn't seem to be a purge option that would work even when occ doesn't have access to the contents of an SMB share in external storage.

@PVince81 PVince81 referenced this issue in icewind1991/SMB Jun 24, 2016
Closed

Ignore read-only attribute on folders #50

@PVince81
Collaborator

I've raised icewind1991/SMB#50 in the icewind1991/SMB library to have it interpret "DR" permissions as read-write for folders.

@jvillafanez
Contributor
jvillafanez commented Jun 27, 2016 edited

Looks like windows wins this time ๐Ÿ˜ญ

  • Windows as server
    • linux mount can write into the read-only folder
    • mac client can write into read-only folder
  • Samba server
    • linux mount can't write into the read-only folder, but probably due to permissions in the client's folder. smbclient can upload files to it without issues
    • mac client can write into the read-only folder

So, we'll have to fix this.

@PVince81
Collaborator

@icewind1991 I think this should be fixed on the library side, permanently to match the above behavior (no config option)

@PVince81
Collaborator

@jvillafanez at least that's better than having big inconsistencies

@PVince81
Collaborator

@jvillafanez ok then, since you insist on having this on app level. Can you add it to the SMB storage implementation ? So: whenever the path is a folder and not a share and that folder has read-only permissions, forward these to ownCloud as read-write permissions.

@jvillafanez
Contributor

๐Ÿ‘

@alankeny

@jvillafanez Did your tests check attributes or permissions?

My test results were similar to yours for attributes. I had to use extra mount options to make the folder writeable on the Linux client, but I could still write to a folder that had the read-only attribute set on the server.

When I granted a user read-only permissions to a folder on the server, none of the clients could write to it. It's important to note that that the client didn't show the read-only attribute on the folder or the files in the folder.

There doesn't seem to be any correlation between permissions and the read-only attribute.

@jvillafanez
Contributor

@alankeny I checked with attributes.

@PVince81 PVince81 modified the milestone: 9.0.5, 9.0.4 Jul 18, 2016
@PVince81
Collaborator

Any update ?

@jvillafanez
Contributor

The PR should be ready now. Read-only folders will allow files to be created and uploaded inside, but the read-only folder won't be deletable.

@alankeny

From KB326549 under the first note under the Cause section:

Unlike the Read-only attribute for a file, the Read-only attribute for a folder is typically ignored by Windows, Windows components and accessories, and other programs. For example, you can delete, rename, and change a folder with the Read-only attribute by using Windows Explorer.

This note explicitly states that folders with the read-only attribute set are deletable from Windows Explorer. I expect OwnCloud and Windows Explorer to handle folders the same way. Please ignore the read-only attribute on folders completely.

@jvillafanez
Contributor

@alankeny I tried deleting the folder from smbclient and I couldn't. Would you mind to recheck this? If smbclient can't delete the folder there is nothing we can do about this.

@alankeny

I created a folder on an SMB share from Windows. I used the attrib command to set the read-only attribute on the folder. I then connected to the share using smbclient on Linux. I verified that smbclient showed the read-only attribute on the folder, and I verified that I was able to remove the folder using smbclient.

There doesn't seem to be any correlation between the read-only attribute and permission to delete the folder. In my experience a read-only attribute on a folder only means that a folder has a customized view in Windows Explorer.

@jvillafanez
Contributor
smb: \MANOLO\MONOS\> dir SUBMONOS/*
  .                                  DR        0  Wed Jul 20 06:55:49 2016
  ..                                 DR        0  Wed Jul 20 06:55:49 2016

        65433 blocks of size 1048576. 30933 blocks available
smb: \MANOLO\MONOS\> dir
  .                                   D        0  Wed Jul 20 06:54:29 2016
  ..                                  D        0  Wed Jul 20 06:54:29 2016
  asdas.txt                          AR        0  Wed Nov 11 11:25:03 2015
  atletaaaaaa.txt                     A        2  Wed Feb 24 15:07:39 2016
  BUHO.jpg                            A    99822  Wed Mar 30 10:50:54 2016
  SUBMONOS                           DR        0  Wed Jul 20 06:55:49 2016

        65433 blocks of size 1048576. 30933 blocks available
smb: \MANOLO\MONOS\> rmdir SUBMONOS
NT_STATUS_CANNOT_DELETE removing remote directory file \MANOLO\MONOS\SUBMONOS

From ubuntu 14.04 (smbclient 4.1.6) to windows server 2008

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment