deblan-mirror/abraunegg-onedrive
deblan-mirror/abraunegg-onedrive
1
0
Fork 0
mirror of https://github.com/abraunegg/onedrive synced 2026-03-14 14:35:46 +01:00
Code Issues Projects Releases Wiki Activity

Update documentation (#3599)

Browse source 
* Update docker documentation to clarify docker mounts as read-write and how to make them read-only for certain scenarios
* Update Ubuntu install guide to fix that ARMHF packages are available for those platforms on the OpenSuSE Build Service
This commit is contained in:
abraunegg 2026-01-09 09:29:34 +11:00 • committed by GitHub
commit 31d2887f71
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
2 changed files with 30 additions and 5 deletions
Download patch file Download diff file Expand all files Collapse all files

29
docs/docker.md
View file

@ -171,7 +171,28 @@ When the Docker container successfully starts:
Once the 'onedrive' application is authorised, the client will automatically start monitoring your `ONEDRIVE_DATA_DIR` for data changes to be uploaded to OneDrive. Files stored on OneDrive will be downloaded to this location.
If the client is working as expected, you can detach from the container with Ctrl+p, Ctrl+q.
If the client is working as expected, you can detach from the container with CTRL+P, CTRL+Q.
#### 6.1. Read-Only / Upload-Only Sync Scenarios
If you are running the Docker container in upload-only mode and want to ensure that the OneDrive client cannot modify the original source files, the data directory must be mounted as read-only.
This is controlled at the container mount level, not by ownership (chown) or permissions (chmod) inside the container.
If this is your desired configuration, you must mount your 'ONEDRIVE_DATA_DIR' with read-only permissions to ensure your data source is immutable and cannot be changed. Augment the above script in the following manner:
```bash
export ONEDRIVE_DATA_DIR="${HOME}/OneDrive"
export ONEDRIVE_UID=`id -u`
export ONEDRIVE_GID=`id -g`
mkdir -p ${ONEDRIVE_DATA_DIR}
docker run -it --name onedrive -v onedrive_conf:/onedrive/conf \
-v "${ONEDRIVE_DATA_DIR}:/onedrive/data:ro" \
-e "ONEDRIVE_UID=${ONEDRIVE_UID}" \
-e "ONEDRIVE_GID=${ONEDRIVE_GID}" \
-e ONEDRIVE_UPLOADONLY=1 \
driveone/onedrive:edge
```
> [!NOTE]
> Essentially, any Docker command where you are mounting your 'ONEDRIVE_DATA_DIR', you need to append `:ro` to the `/onedrive/data` specification to ensure your data directory is mounted in Docker as read-only volume.
### 7. Running the 'onedrive' container under 'docker'
@ -200,7 +221,6 @@ docker start onedrive
docker rm -f onedrive
```
### Customising OneDrive Runtime Behaviour in Docker
When running the OneDrive client inside Docker, the container **always starts** via `entrypoint.sh`, which ensures that the following arguments are added automatically:
@ -217,6 +237,11 @@ This design guarantees that:
Because these arguments are always supplied, any `sync_dir` or `confdir` values defined in the configuration file are **overridden at runtime by design**. This avoids confusion and ensures predictable behaviour. These specific paths are the bind-mounts between container and host and should **not be changed manually**.
#### Default Docker volume behaviour
By default, Docker bind mounts and volumes are mounted read-write inside the container. This means that, unless explicitly restricted, the container process may create, modify, rename, or delete files within the mounted directory, subject to normal filesystem permissions.
#### Using read-only mounts
If you want to prevent the container from modifying the mounted data (for example, in upload-only or backup-style scenarios), the bind mount must be explicitly marked as read-only using the `:ro` mount option. A read-only mount enforces immutability at the container boundary and cannot be overridden from inside the container, regardless of ownership or permissions.
### Supported ways to customise runtime behaviour

6
docs/ubuntu-package-install.md
View file

@ -338,7 +338,7 @@ Read and understand the [known issues](#known-issues-with-installing-from-the-ab
The packages support the following platform architectures:
|  i686  | x86_64 | ARMHF | AARCH64 |
|:----:|:------:|:-----:|:-------:|
|❌|✔|❌|✔|
|❌|✔|✔|✔|
#### Step 1: Add the OpenSuSE Build Service repository release key
Add the OpenSuSE Build Service repository release key using the following command:
@ -365,7 +365,7 @@ Read and understand the [known issues](#known-issues-with-installing-from-the-ab
The packages support the following platform architectures:
|  i686  | x86_64 | ARMHF | AARCH64 |
|:----:|:------:|:-----:|:-------:|
|❌|✔|❌|✔|
|❌|✔|✔|✔|
#### Step 1: Add the OpenSuSE Build Service repository release key
Add the OpenSuSE Build Service repository release key using the following command:
@ -392,7 +392,7 @@ Read and understand the [known issues](#known-issues-with-installing-from-the-ab
The packages support the following platform architectures:
|  i686  | x86_64 | ARMHF | AARCH64 |
|:----:|:------:|:-----:|:-------:|
|❌|✔|❌|✔|
|❌|✔|✔|✔|
#### Step 1: Add the OpenSuSE Build Service repository release key
Add the OpenSuSE Build Service repository release key using the following command: