Found the problem:

 

When i try to login to the DB as user 'owncloud' using the console it works, so my credentials are correct.

When i use the root credentials rather then the owncloud users i can create my admin user and everything work.

 

As a result i think the 'owncloud' user does not have all the required permissions to run owncloud.

There is an issue on github with this exact problem from 2019.

Hi all,

I'm facing an issue and I'm not able to fix it.
I had some trouble deleting files using the web ui.
After changing the rights, it worked fine. Afterwards I noticed the new version. As a backup I did 'cp -r owncloud owncloud.old'.
I know that dlandon describes in the update manual to rename the folder. However, when I restarted the docker container after the copy process, I'm facing the following error:
 

2024/08/25 19:31:13 [error] 534#534: *41 FastCGI sent in stderr: "PHP message: PHP Fatal error:  Uncaught Doctrine\DBAL\DBALException: Failed to connect to the database: An exception occurred in driver: SQLSTATE[HY000] [2002] No such file or directory in /config/www/owncloud/lib/private/DB/Connection.php:62
Stack trace:
#0 /config/www/owncloud/lib/composer/doctrine/dbal/lib/Doctrine/DBAL/Connection.php(475): OC\DB\Connection->connect()
#1 /config/www/owncloud/lib/composer/doctrine/dbal/lib/Doctrine/DBAL/Connection.php(437): Doctrine\DBAL\Connection->getDatabasePlatformVersion()
#2 /config/www/owncloud/lib/composer/doctrine/dbal/lib/Doctrine/DBAL/Connection.php(379): Doctrine\DBAL\Connection->detectDatabasePlatform()
#3 /config/www/owncloud/lib/composer/doctrine/dbal/lib/Doctrine/DBAL/Connection.php(844): Doctrine\DBAL\Connection->getDatabasePlatform()
#4 /config/www/owncloud/lib/private/DB/Connection.php(148): Doctrine\DBAL\Connection->setTransactionIsolation()
#5 /config/www/owncloud/lib/composer/doctrine/dbal/lib/Doctrine/DBAL/DriverManager.php(262): OC\DB\Con" while reading response header from upstream, client: x.x.x.x, server: _, request: "GET /status.php HTTP/1.1", upstream: "fastcgi://unix:/var/run/php/php7.4-fpm.sock:", host: "my-domain.com"

 

Asking google I found some hints in missing php modules. I changed the php version via 'Edit' in the unraid web ui regarding to the owncloud docker container. This led to pulling and (re)installing the php packets during the start of the docker container. Nevertheless, I'm still facing this issue.

 

Used php version is 7.4

Any tips or ideas?

UPDATE:
Database log says:

Quote

2024-08-25 20:02:10 0 [ERROR] Found 1 prepared transactions! It means that mysqld was not shut down properly last time and critical recovery information (last binlog or tc.log file) was manually deleted after a crash. You have to start mysqld with --tc-heuristic-recover switch to commit or rollback pending transactions.
2024-08-25 20:02:10 0 [ERROR] Aborting

Honestly, I'm not good in database administration. More precisely: I hate databases

How can I do this within the container? -> start mysqld with --tc-heuristic-recover switch to commit or rollback pending transactions

 

UPDATE 2:
I'm lost ....

Quote

 mysqld --tc-heuristic-recover=ROLLBACK
2024-08-25 20:12:37 0 [Note] Starting MariaDB 10.4.34-MariaDB-1:10.4.34+maria~ubu2004-log source revision 16394f1aa1b4097f897b8ab01ea2064726cca059 as process 21659
2024-08-25 20:12:37 0 [ERROR] mysqld: Can't lock aria control file '/config/database/aria_log_control' for exclusive use, error: 11. Will retry for 30 seconds
2024-08-25 20:12:59 0 [Note] InnoDB: Using Linux native AIO
2024-08-25 20:12:59 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2024-08-25 20:12:59 0 [Note] InnoDB: Uses event mutexes
2024-08-25 20:12:59 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
2024-08-25 20:12:59 0 [Note] InnoDB: Number of pools: 1
2024-08-25 20:12:59 0 [Note] InnoDB: Using SSE2 crc32 instructions
2024-08-25 20:12:59 0 [Note] InnoDB: Initializing buffer pool, total size = 256M, instances = 1, chunk size = 128M
2024-08-25 20:12:59 0 [Note] InnoDB: Completed initialization of buffer pool
2024-08-25 20:12:59 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority().
2024-08-25 20:13:00 0 [Note] InnoDB: Transaction 21687468 was in the XA prepared state.
2024-08-25 20:13:00 0 [Note] InnoDB: 1 transaction(s) which must be rolled back or cleaned up in total 0 row operations to undo
2024-08-25 20:13:00 0 [Note] InnoDB: Trx id counter is 21687469
2024-08-25 20:13:00 0 [Note] InnoDB: 128 out of 128 rollback segments are active.
2024-08-25 20:13:00 0 [Note] InnoDB: Starting in background the rollback of recovered transactions
2024-08-25 20:13:00 0 [Note] InnoDB: Rollback of non-prepared transactions completed
2024-08-25 20:13:00 0 [Note] InnoDB: Creating shared tablespace for temporary tables
2024-08-25 20:13:00 0 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
2024-08-25 20:13:00 0 [Note] InnoDB: File './ibtmp1' size is now 12 MB.
2024-08-25 20:13:00 0 [Note] InnoDB: 10.4.34 started; log sequence number 6068690492; transaction id 21687470
2024-08-25 20:13:00 0 [Note] Plugin 'FEEDBACK' is disabled.
2024-08-25 20:13:00 0 [Note] InnoDB: Loading buffer pool(s) from /config/database/ib_buffer_pool
2024-08-25 20:13:00 0 [Note] InnoDB: Buffer pool(s) load completed at 240825 20:13:00
2024-08-25 20:13:00 0 [Note] Heuristic crash recovery mode
2024-08-25 20:13:00 0 [Note] InnoDB: Starting recovery for XA transactions...
2024-08-25 20:13:00 0 [Note] InnoDB: Transaction 21687468 in prepared state after recovery
2024-08-25 20:13:00 0 [Note] InnoDB: Transaction contains changes to 1 rows
2024-08-25 20:13:00 0 [Note] InnoDB: 1 transactions in prepared state after recovery
2024-08-25 20:13:00 0 [Note] Found 1 prepared transaction(s) in InnoDB
2024-08-25 20:13:00 0 [Note] Please restart mysqld without --tc-heuristic-recover
2024-08-25 20:13:00 0 [ERROR] Can't init tc log
2024-08-25 20:13:00 0 [ERROR] Aborting

BR
Sascha

Edited August 25, 20241 yr by bonox

Super great work getting it all working in one box. Two notes.

 

On 6/3/2017 at 1:16 PM, dlandon said:

To install the docker from scratch:

• Install docker and then go to the WebUI.
• Enter an administration user and password.
• Change the data folder to /data.
• Because the database is built into the container, the database host is localhost.
• The database user and the database itself are both 'owncloud'.
• If you do not change the default DB_PASS variable, the default database password is 'owncloud'.
• Once in the ownCloud WebUI, go to 'Settings->General' and click the 'Cron' method for the cron.php task.  A cron to perform this is built into the docker.
• If you use your own certificate keys name them cert.key and cert.crt, and place them in config/keys folder.

Respectfully; I strongly suggest putting this in the Template's "Overview" section for the Container Template itself. None of this is intuitive or safely assumed. There's no limit on how much text you can put there, and you already have sections for configuration -and- notes there, which are also required to set up the container -- but not listed in the Install text above. Putting this information all together and in the Overview would remove "go to the Support forum for more information" from the unlisted requirements to using this container.

 

 

Also, regarding "Change the data folder to /data" -- why not just bind the user's data volume to `/config/www/owncloud/data` (which is OwnCloud's actual default) instead? If the template default is to bind to `/config/www/owncloud/data` instead of `/data` new users don't need to change the data folder, it will simply "just work" without that step. The user won't see any difference. Presently, if the user doesn't know to do this or misses/misconfigures this step, their database gets wiped when the container updates and they just suddenly lose stuff.

 

 

7 hours ago, bonox said:

...

 

I had some trouble deleting files using the web ui.

 

After changing the rights, it worked fine.

...

 

the following error:

...

 

I changed the php version .. owncloud docker container.

...

 

still facing this issue.

 

...

 

Database log says:

 

...

 

How can I do this within the container?

 

...

 

(Snipped for brevity)

 

What does "some trouble" mean? Were you unable to delete things you should have had the rights to? How did you resolve it? What other actions did you take after it would not delete? (ie; closing/killing the container, recreating the container, reading logs, etc)

 

When you copied the folder, was the container still running? This is a Very Bad Thing(tm), as files are not in a "ready to be archived" state during operation; lock files exist which should not, temporary files exist which are not necessary, in-progress operations can be clipped, files are very much not properly committed to disk (ESPECIALLY with a database engine) etc.

 

The -first- error you mentioned indicates that DBAL was unable to connect to the database. PHP was working, or DBAL would not have been running. DBAL was working; it was merely unable to connect to the databse, which is not an internal failure to DBAL or PHP. This was your indication that the database was your first problem. Changing the PHP version was not a good idea and not relevant to repair, and it should be changed back.

 

The actual error is indicated in your DB message. `"mysqld was not shut down properly last time and critical recovery information (last binlog or tc.log file) was manually deleted after a crash"` -- aka, you copied a bunch of files from a running databse system and later restored them by erasing the existing files and copying the "while-running" files back, or it crashed and a bunch of files were lost/damaged.

 

(PS: Never, ever restore database files over other database files after an update/downgrade; between versions, database engines and software using databases sometimes make broad, sweeping changes to database structure and/or database layout. Simply wiping and replacing the files does not prepare them to be understood by a different version. Sometimes this is safe, when it isn't it breaks absolutely everything. It's not worth the risk.)

 

`How can I do this within the container? -> start mysqld with --tc-heuristic-recover switch to commit or rollback pending transactions`

Before I answer that part -- this may or may not actually be a good idea now. After having so many things changed, and doubtless changes have been made which you have not mentioned, the system is in a very unknown state. Someone needs to sit down with you, talk over everything you did, decide if any of it needs to be reverted (and in what order) and settle the best next action from that point.

 

That said --

 

Given that this is an all-in-one container, mysqld is instantly restarted as soon as it goes down. As such, this container can not be used to fix this problem. It is possible for an experienced database/Docker user to use a mysql container with your cleanest copy of the database files to recover from this situation. If you're that user;

- You need to create a new container using the same mysqld (or mariadb, I haven't checked) version, using the same database config file this container does, with the same volumes mounted to the same places.

- When launching the container, you need to override the startup of the container to instead run only a shell.

- Manually launch the database daemon with the `-tc-heuristic-recover` flag added to the usual start-up command.

 

This could also be done using WSL or a Linux boot medium, the process is more or less the same, and definitely not approached by someone who doesn't understand what's going on.

 

TL;DR -- find a pro, or wipe it and start over.

 

Having an issue where I can not use the desktop app to login - getting a invalid username password message.

However I am able to login via the web ui just fine.

It has been proxied and is working fine remotely just unable to login with the desktop app.

I turned off the MFA as I saw a post about it on the owncloud forums - and tried to enable OAUTH but got a 403 error when attempting that way even though I am successfully logged in in that same browser session.

Same thing happens when logging in with the Android App - but I can access it from browser just fine.

 

Nothing stands out in logs to my quick uneducated look over it.

Server log

https://pastebin.com/unMmhBjj

 

Any ideas here on where I have gone wrong?

 

This may be a stupid question, but how can I integrate the container so that I can access my existing data? 
I have integrated it this way, but can't see any of my data:

 

In Owncloud (logged in as admin), however, I do not see the data & folders. I would not like to include them as “External storage” and would like them to be displayed in “All files”.

Attempting to integrate the new tailscale available on 7.0.0 within this docker container.   I'm receiving the following error messages (repeating):
 

nginx: [emerg] bind() to 0.0.0.0:443 failed (98: Address already in use)

nginx: [emerg] bind() to 0.0.0.0:443 failed (98: Address already in use)

nginx: [emerg] bind() to 0.0.0.0:443 failed (98: Address already in use)

I assume this is due to tailscale also using 443 within the docker.   But not sure if it's possible to set this so that I can access via tailscale instead of using nginx/reverse proxy?

On 6/3/2017 at 1:16 PM, dlandon said:

Manual update is the recommended way to update an existing ownCloud installation.

• Disable apps - Calendar, Contacts, and any add on apps - Settings->Apps.
• Access the ownCloud Docker 'docker exec -it ownCloud bash'.
• Install nano 'apt-get install nano'.
• Put ownCloud in maintenance mode by editing 'nano /config/www/owncloud/config/config.php'.
• Stop ownCloud docker from the unRAID Docker UI.
• Get into the unRAID command line.
• Change directory to 'cd /mnt/user/appdata/ownCloud/www'.
• Move the existing owncloud version 'mv ./owncloud ./owncloud-old'.
• Download and unzip the owncloud update from here.  Copy update using a PC to \appdata\ownCloud\www\.
• Go back to the Unraid command line.
• Copy external apps 'cp -R /mnt/user/appdata/ownCloud/www/owncloud-old/apps-external/ /mnt/user/appdata/ownCloud/www/owncloud/apps-external/'.
• Change ownership 'chown nobody:users owncloud'.
• Copy the old version of config.php 'cp /mnt/user/appdata/ownCloud/www/owncloud-old/config/config.ph /mnt/user/appdata/ownCloud/www/owncloud/config/config.php'.
• Start owncloud docker from unRAID Docker UI.
• Access the ownCloud Docker 'docker exec -it ownCloud bash'.
• Change directory to new owncloud version 'cd /config/www/owncloud'.
• Change occ to executable 'chmod +x occ''
• Execute upgrade: 'sudo -u abc ./occ upgrade'.
• Change permissions on owncloud 'chmod 755 /config/www/owncloud'.
• Take ownCloud out of maintenance mode by editing 'nano /config/www/owncloud/config/config.php'.
• Re-enable apps - Calendar, Contacts, and any add on apps.

love how this still works today

Struggling to get ownCloud to work with my NginxProxyManager-Official setup, not sure what else to try. I've searched the git repo and tried 2 different solutions that haven't worked out and reinstalled ownCloud multiple times to ensure I have a clean install (deleted local folders as well).

 

ownCloud nginx logs:

The top entry is over my NPM instance https://owncloud.domain.domain.org and it displays nothing inside "All Files" in ownCloud ui or it says "You don't have permission to upload or create files here" (initially it said no permission for awhile but now it just always just has a blank 'All Files' page)

The bottom entry is when I login over the local connection at https://192.168.1.210 and it successfully shows my files in "All Files"

192.168.1.206 - - [23/Jan/2025:13:24:27 -0000] "PROPFIND /remote.php/dav/files/null/ HTTP/1.1" 404 6571 "-" "{UserAgent}"

192.168.1.235 - - [23/Jan/2025:13:21:56 -0000] "PROPFIND /remote.php/dav/files/testuser/ HTTP/1.1" 207 2979 "-" "{UserAgent}"

192.168.1.206 is NginxProxyManager-Official
192.168.1.235 is my local pc
192.168.1.210 is owncloud

 

ownCloud config.php lines I changed:

  'trusted_domains' => 
  array (
    0 => '192.168.1.210',
    1 => 'owncloud.domain.domain.org',
    2 => '192.168.1.206',
  ),
'overwrite.cli.url' => 'https://192.168.1.210',

 

As for my NPM instance I disabled "Block Common Exploits" as I saw someone said it gave them an error and that's it. It uses this proxy host below and everything is default except my cert and "Cache Assets".

https://192.168.1.210:443

 

Other than that my NPM install is a little special (that might be the issue) so I could get it to work with AdGuard.

It's on bro with its own IP and then in the post-args I add this so it can communicate to my custom network

docker network connect customentworkname Nginx-Proxy-Manager-Official

 

Anyone ran into a similar issue or know a possible solution; anything is greatly appreciated!

Edited January 24, 20251 yr by bristopher

On 1/15/2025 at 4:43 PM, konaboy said:

Attempting to integrate the new tailscale available on 7.0.0 within this docker container.   I'm receiving the following error messages (repeating):
 

nginx: [emerg] bind() to 0.0.0.0:443 failed (98: Address already in use)

nginx: [emerg] bind() to 0.0.0.0:443 failed (98: Address already in use)

nginx: [emerg] bind() to 0.0.0.0:443 failed (98: Address already in use)

I assume this is due to tailscale also using 443 within the docker.   But not sure if it's possible to set this so that I can access via tailscale instead of using nginx/reverse proxy?

Running into the same issue here. When I disable Tailscale it all works fine, but when enabled it'll spit out the above error. Changing the Tailscale port from 443 to something else doesn't seem to affect anything and it seems I can't even change the OwnCloud port.

 

Based on information from @ich777 in this post:

I've changed the following...  It's not fully working yet with Tailscale, however I think I'm on the right path.. putting this in here now, since I'm going to bed soon, and already typed all of this in...!!  will revist tomorrow. 

 

1. remove the WebUI Port configuration. Not the what host port you are currently using for step 2. 

 

2. Add a new port using Containter port of something other than 443.  I used 8443:

 

3. Ensure Owncloud container is stopped, and in your appdata path, edit appdata\ownCloud\nginx\site-confs\default

      change:

         server {
          listen 443 ssl;
          server_name _;

     to:

     server {
          listen 8443 ssl;
          server_name _;

Use the new container port number you used in step 2 above.

Save the updated file.

 

4. Back in Unraid, Docker, apply the changes you made in step 2.    Test to make sure everything is working properly.

/////////

 

5. Turn on Tailscale per the normal instructions on how to do that in the docker container.

6. Apply, then test to make sure you can still get to owncloud however you were before (I can).
////
I've made the following changes so far, however can not yet get to owncloud via the tailscale url...

 

7.  I updated appdata\ownCloud\www\owncloud\config\config.php trusted domains...  (the 0 => entry was already there)...

 

'trusted_domains' => 
  array (
    0 => 'owncloud.mydomain.com',
    1 => 'owncloud.tailscale-friendly-name.net',
    2 => 'x.xxx.xxx.xx',

wher x.xxx.xxx.xx is the tailscale IP address for my owncloud

 

I can't access owncloud via tailscale, getting an http error 502.   

 

I'll continue tomorrow.!!

 

 

4 hours ago, konaboy said:

I'll continue tomorrow.!!

I'll probably can save you some time here.

 

Try the attached default for nginx in the container, it uses port 80 for Tailscale and port 8443 for SSL like you've already configured it, instead of redirecting port 80 to 443 it serves now Owncloud on port 80 for Tailscale.

Of course you have to also change the Tailscale Serve port in the Docker template (with Advanced Tailscale options enabled) to port 80.

 

This should be safe since you've probably only forwarded port 8443 in your router anyways to be able to access Owncloud via https.

 

Tailscale just proxies port 80 to 443 and makes it then available in your Tailnet.

 

Here is the default file for nginx:
default

 

Don't forget to change the port in the Docker template for Serve to port 80:

 

 

Here you can see it is reachable locally:

 

And here you can see I can also reach it via my Tailnet Domain:

 

 

I hope that helps, you can of course also configure it differently that 80 redirects to 8443 in the container and use a different port for Tailscale.

7 hours ago, ich777 said:

I hope that helps

 

Thanks very much!.  This got me going.    I am running Nginx Proxy Manager along with Cloudflare, so I have 443 and 80 forwarded from my router to NPM.    

My goal here is to move everything away from NPM/Cloudflare over to tailscale.  Since I only have a couple of remote family members that I support with some apps, I'd like to close all of my open/forwarded ports and use just tailscale.   [my next step, now that I know I can use owncloud via tailscale is to read up more on tailscale vs npm/cloudflare].

4 minutes ago, konaboy said:

My goal here is to move everything away from NPM/Cloudflare over to tailscale.  Since I only have a couple of remote family members that I support with some apps, I'd like to close all of my open/forwarded ports and use just tailscale.

Oh, if this is your goal then just use this config, this just uses port 80:

default

 

Strictly speaking you don't need port 443, you then could even use Funnel with Tailscale to make your Owncloud accessible through your Tailscale Domain.

10 hours ago, ich777 said:

Oh, if this is your goal then just use this config, this just uses port 80:

default 3.01 kB · 0 downloads

 

Strictly speaking you don't need port 443, you then could even use Funnel with Tailscale to make your Owncloud accessible through your Tailscale Domain.

Thanks ich777 - I'll do that.  I'm currently working through how to change my owncloud clients (I've got a couple of window VMs, and a Mac that I keep in sync with owncloud) to the new url.  I understand how to do it, just want to test that a bit! before I turn off the cloudflare/nginx based url.

 

And I appreciate all your work here on the forums, and with your applications/support.    And grin - just saw that you "won the day" yesterday as most liked content here on the forums!!  congrats.

Hi I'm hoping i'm in the right spot to post this!

I'm having issues with Owncloud docker webgui and desktop and not sure where to start.

Background;

I recently moved and setup my server once again at the new place (unraid). Had to switch USB keys and thus GUID which went ok but am stuck at the OwnCloud setup. When trying my old IP it would tell me that the authorization wasn't allowed. When switching the IP in the config file on my local desktop it now says 'Your Data directory is invalid. Please check that the data directory contains a file ".ocdata" in its root.

I don't see that anywhere within my desktop.

I'm not sure how to proceed to access my files (owncloud) within the server now so any help or suggestions would be greatly appreciated.

Thank you so much!

IMPORTANT UPDATE NOTICE

The next release of the ownCloud Docker Container will have several changes that will affect your ability to properly update the ownCloud container. Because of the Mariadb EOL cycle, it has become very difficult to build a new container using older versions of Mariadb. Mariadb has a bad habit of removing EOL versions from distribution. The other consideration is that Mariadb 10.5 seems to be the last version supported on Ubuntu Focal. This is complicated by the fact that ownCloud 10.9 and later support Mariadb 10.6. To accomodate these changes the container is being changed:

• Update container to Ubuntu Jammy.

• Update Mariadb to 10.6.

• Remove php 7.2 and 7.3. This was done for legacy purposes for older versions of ownCloud, but it is no longer necessary. The PHP line in the template will no longer be used.

You have several options and need to make a decision before the next release of the Docker container. It is recommended to make a backup of your ownCloud "appdata/ownCloud" folder before doing anything.

Upgrade ownCloud:

Upgrade to ownCoud 10.9 or later before updating the container. If you are already at ownCloud 10.9 or greater, just update the container when it is available.

Maintain what you have:

There is a legacy container that you can install that keeps your system where it is right now. Edit your ownCloud template and change the "Repository:" line to "dlandon/owncloud:legacy" and install the legacy container. There will be no more updates to the "legacy" container.

The legacy container is already available and you can go ahead and install that now and prevent an accidental update you may not want.

In the long run, you should update ownCloud to 10.15 or the latest version and then update the container. You would do this by setting the Repository:" line back to "dlandon/owncloud" after updating ownCloud.

CAUTION: If you accidently update the container with a version of ownCloud older than 10.9, the database will be updated to Mariadb 10.6 and you will then have to update ownCloud to 10.9 or later manually to get ownCloud working again. The database cannot be rolled back to an older version.

This change will not be made for at least a month, so you some have time to prepare.

Edited September 15, 2025Sep 15 by dlandon

On 8/22/2022 at 5:18 AM, jlfoco said:

 

I don't know if its helpful, but I was able to run the following command to execute the scan of the manually moved files. i.e., moving files across shares in Unraid. 

 

sudo -u abc ./config/www/owncloud/occ files:scan --all

 

 

I need to scan all files that I moved from nextcloud to owncloud but I need to scan it, But it dooesn work

Just noticed around the end of July my owncloud account was throwing off permission errors. Oddly I signed into another account in my home owncloud docker instance and it doesn't show "You don't have permission to upload or create files in here". I've tried changing the permissions in the docker to abc:user and in unraid nobody:users and a data folder 755 permissions, I feel like this issue started when my cache disk needed to be replaced in unraid. I also redirect the data in the /mnt/user/home/owncloud/data location in unraid. I've tried every thing but I can't seem to fix my accounts permissions issue in Owncloud, can anyone advise if I've messed up my permissions somehow?

Post docker run

On 8/5/2025 at 1:20 PM, Atorcha said:

I need to scan all files that I moved from nextcloud to owncloud but I need to scan it, But it dooesn work

Edit your config.php file: nano /config/www/owncloud/config/config.php and confirm the following:

• 'datadirectory' is set to 'data'

• set 'file_system_check_changes' to '1'

ownCloud should over time scan and add the files found. It's not immediate. I haven't done this for quite a while, but when I last did it, it worked.

On 8/21/2025 at 9:47 PM, Steven81 said:

Just noticed around the end of July my owncloud account was throwing off permission errors. Oddly I signed into another account in my home owncloud docker instance and it doesn't show "You don't have permission to upload or create files in here". I've tried changing the permissions in the docker to abc:user and in unraid nobody:users and a data folder 755 permissions, I feel like this issue started when my cache disk needed to be replaced in unraid. I also redirect the data in the /mnt/user/home/owncloud/data location in unraid. I've tried every thing but I can't seem to fix my accounts permissions issue in Owncloud, can anyone advise if I've messed up my permissions somehow?

You shouldn't change any permissions. ownCloud is very particular about permissions and manual changes can cause problems. I recommend you set the advanced view on the dockers page and click on "force update". The docker container should fix permissions on most everything in the /config directory when it does a first start.

On 8/23/2025 at 2:24 PM, dlandon said:

Edit your config.php file: nano /config/www/owncloud/config/config.php and confirm the following:

• 'datadirectory' is set to 'data'

• set 'file_system_check_changes' to '1'

ownCloud should over time scan and add the files found. It's not immediate. I haven't done this for quite a while, but when I last did it, it worked.

Thanks @dlandon, I really appreciate the suggestions with regards to this issue. I did a force update as you suggested to repair any permissions changes, and I updated config.php as you suggested. I didn't find the 'file_system_check_changes' defined in the php file so I had to manually enter it in and restarted the docker. Fingers crossed it works, I'll monitor and see if my permissions issue gets any better.

On 8/21/2025 at 11:19 PM, trurl said:

Post docker run

@trurl here's the docker run, I haven't changed much in the settings in a long time.

IMPORTANT UPDATE NOTICE

In the next few days I will be updating the ownCloud Container and you need to prepare for this. You need to do the following:

• Read this post about the update: https://forums.unraid.net/topic/57801-support-dlandon-owncloud/page/18/#findComment-1571314

• Decide if you want to accept the update or stay with the current Container.

• If you choose to update, be sure to make a backup of your appdata/ownCloud folder.

Edited September 30, 2025Sep 30 by dlandon