Thanks Vincent, Le 27 avr. 2015 à 15:21, Vincent Petry <[email protected]> a écrit : > Please NEVER truncate the file cache, it will lose all references to shares, > tags, favorites, etc.
Ok, so it’s not realy a … file cache ;-) > You said you had duplicate entries in oc_storages (possibly like > https://github.com/owncloud/core/issues/13980#issuecomment-73511661 > <https://github.com/owncloud/core/issues/13980#issuecomment-73511661>) > Maybe you removed the wrong home ? Effectively, during the post installe upgrade (on web interface) I had a message which said I had a duplicate entry: one with a « home::UUID » and the other with « local::/owncloud/data/UUID ». I found these entries in oc_storage, not exactly because the second one were just « local::/owncloud/data ». When I saw which records correspond to this ID in oc_filecache, there was a lot of lines refer lot of users home dir… Until I delete the reference ID "local" in the table oc_storage AND I deleted all references to the same ID in the oc_filecache table, the post-installation of the upgrade script refused always finish. After everything seemed to work, I had my share of active files, so I thought everything was good. A great mistake! > You can check the "oc_share" entries, look at "file_source" and map it with > the "fileid" from oc_filecache. Then map "oc_filecache" with "oc_storages": > MariaDB [owncloud]> select > s.id,f.fileid,f.path,sh.uid_owner,sh.share_type,sh.share_with from oc_share > sh left join oc_filecache f on sh.file_source=f.fileid left join oc_storages > s on s.numeric_id=f.storage; > > If you see "NULL" in the first column, it means that the storage entry is now > missing and the shares are orphaned. > If the number of shares is small, you could manually remap their > "item_source" and "file_source" to point to the correct file id. All lines are « NULL »… :-( > Or you could recreate the missing "oc_storages" entry and rename it to the > new/correct name so that the user in question will use the older cache > (hopefully 2 days would not have changed too many files). If you do this, you > might need to run "./occ files:scan userx" for that user (userx being the > user you just repaired) to make sure the cache entries get updated in case > files have been changed since the last cache update. > > There is no efficient and fail-proof way to fix this automatically, > unfortunately. I see. Is, if I ask all users with file shares that have disappeared to create these shares again, it can work again without letting mistakes next? It's because there were still bad references in the database after updating OC 4 to OC 5 which strongly changed the LDAP users referencing that I had these problems. Regards > > Regards, > > Vincent > > On 27.04.2015 15:11, Pierre Malard wrote: >> I forgot something, >> >> When I open the « admin » page, now I have this: >> Configuration Checks >> >> Your data directory and your files are probably accessible from the >> internet. The .htaccess file is not working. We strongly suggest that you >> configure your webserver in a way that the data directory is no longer >> accessible or you move the data directory outside the webserver document >> root. >> Please double check the installation guides. >> >> I read the install guide, My Apache configuration is standard: >> <VirtualHost 193.48.189.76:443> >> ServerName cumulus.teledetection.fr >> ServerAdmin [email protected] >> <mailto:[email protected]> >> >> DocumentRoot /var/www/owncloud_prod >> <Directory /var/www/owncloud_prod/> >> AllowOverride All >> </Directory> >> >> And all permission have been set like admin doc say it >> (https://doc.owncloud.org/server/8.0/admin_manual/installation/source_installation.html#setting-strong-directory-permissions >> >> <https://doc.owncloud.org/server/8.0/admin_manual/installation/source_installation.html#setting-strong-directory-permissions>) >> >> All .htaccess are like originals and the data directory is not accessible >> directly. >> >> I dont understand! >> >>> Le 27 avr. 2015 à 14:36, Pierre Malard <[email protected]> >>> <mailto:[email protected]> a écrit : >>> >>> Hi, >>> >>> After most problems with « old » references in « oc_storages » (like « >>> local::/owncloud/data »), I have suppress all these references in >>> oc_storages and oc_filecache. Everything seem to be OK but… >>> >>> Now, after 2 days, all directories or files that I shared are no longer >>> marked as shared ! >>> >>> If I take a look on oc_share table, they are still here but not on display. >>> The only visible difference is the addition of the directory ‘/Shared' >>> reference to the actual file-sharing in the target field. For example, if >>> my repertoire to share in ‘/Partage', 'file-target' records >>> '/Shared/Partage’. >>> >>> In ‘data/owncloud.log’, I have a lot of lines like: >>> {"reqId":"c7ea3156abb1c3595af3073d35a494d6","remoteAddr":"","app":"PHP","message":"unlink() >>> expects parameter 2 to be resource, integer given at >>> \/var\/www\/owncloud\/lib\/private\/cache\/fileglobalgc.php#50","level":3,"time":"2015-04-27T12:30:01+00:00"} >>> >>> Is it a « cache » problem? >>> >>> Is it possible to flush the oc_filecache table to solve this problem? >>> >>> -- >>> Pierre Malard >>> >>> « C'est bien plus beau lorsque c'est inutile » >>> E Rostand - "Cyrano de Bergerac" >>> |\ _,,,---,,_ >>> /,`.-'`' -. ;-;;,_ >>> |,4- ) )-,_. ,\ ( `'-' >>> '---''(_/--' `-'\_) πr >>> >>> perl -e '$_=q#: 3|\ 5_,3-3,2_: 3/,`.'"'"'`'"'"' 5-. ;-;;,_: |,A- ) )-,_. >>> ,\ ( `'"'"'-'"'"': '"'"'-3'"'"'2(_/--'"'"' `-'"'"'\_): >>> 24πr::#;y#:#\n#;s#(\D)(\d+)#$1x$2#ge;print' >>> - --> Ce message n’engage que son auteur <-- >>> >>> _______________________________________________ >>> User mailing list >>> [email protected] <mailto:[email protected]> >>> http://mailman.owncloud.org/mailman/listinfo/user >>> <http://mailman.owncloud.org/mailman/listinfo/user> >> -- >> Pierre Malard >> >> « Tous les Français ambitionnent pour la France un grand rôle >> dans le monde. Ce n'est point par des aventures guerrières qu'elle >> le trouvera, c'est en donnant aux peuples l'exemple et le signal >> de justice. » >> Jean Jaures - "L'idéal de >> justice" - 1889 >> |\ _,,,---,,_ >> /,`.-'`' -. ;-;;,_ >> |,4- ) )-,_. ,\ ( `'-' >> '---''(_/--' `-'\_) πr >> >> perl -e '$_=q#: 3|\ 5_,3-3,2_: 3/,`.'"'"'`'"'"' 5-. ;-;;,_: |,A- ) )-,_. >> ,\ ( `'"'"'-'"'"': '"'"'-3'"'"'2(_/--'"'"' `-'"'"'\_): >> 24πr::#;y#:#\n#;s#(\D)(\d+)#$1x$2#ge;print' >> - --> Ce message n’engage que son auteur <-- >> >> >> >> _______________________________________________ >> User mailing list >> [email protected] <mailto:[email protected]> >> http://mailman.owncloud.org/mailman/listinfo/user >> <http://mailman.owncloud.org/mailman/listinfo/user> > > _______________________________________________ > User mailing list > [email protected] > http://mailman.owncloud.org/mailman/listinfo/user -- Pierre Malard « La vérité ne triomphe jamais, mais ses ennemis finissent toujours par mourir... » Max Placnk (1858-1947) |\ _,,,---,,_ /,`.-'`' -. ;-;;,_ |,4- ) )-,_. ,\ ( `'-' '---''(_/--' `-'\_) πr perl -e '$_=q#: 3|\ 5_,3-3,2_: 3/,`.'"'"'`'"'"' 5-. ;-;;,_: |,A- ) )-,_. ,\ ( `'"'"'-'"'"': '"'"'-3'"'"'2(_/--'"'"' `-'"'"'\_): 24πr::#;y#:#\n#;s#(\D)(\d+)#$1x$2#ge;print' - --> Ce message n’engage que son auteur <--
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ User mailing list [email protected] http://mailman.owncloud.org/mailman/listinfo/user
