This project provides a lightweight and secure Docker container for Sharry.
Note
This Docker container is entirely unofficial and not made by the creators of Sharry.
Sharry allows to share files with others in a simple way. It is a self-hosted web application. The basic concept is: upload files and get a url back that can then be shared.
- Quick Start
- Usage
- Docker Image Versioning and Tags
- Docker Image Update
- User/Group IDs
- Shell Access
- Accessing the GUI
- Built-in Administrator Account
- Customizing Sharry Configuration
- Exposing Sharry to the Internet
- Support or Contact
Important
The Docker command provided in this quick start is an example, and parameters should be adjusted to suit your needs.
Launch the Sharry docker container with the following command:
docker run -d \
--name=sharry \
-p 9090:9090 \
-v /docker/appdata/sharry:/config:rw \
jlesage/sharryWhere:
/docker/appdata/sharry: Stores the application's configuration, state, logs, and any files requiring persistency.
Access the Sharry GUI by browsing to http://your-host-ip:9090.
docker run [-d] \
--name=sharry \
[-e <VARIABLE_NAME>=<VALUE>]... \
[-v <HOST_DIR>:<CONTAINER_DIR>[:PERMISSIONS]]... \
[-p <HOST_PORT>:<CONTAINER_PORT>]... \
jlesage/sharry| Parameter | Description |
|---|---|
| -d | Runs the container in the background. If not set, the container runs in the foreground. |
| -e | Passes an environment variable to the container. See Environment Variables for details. |
| -v | Sets a volume mapping to share a folder or file between the host and the container. See Data Volumes for details. |
| -p | Sets a network port mapping to expose an internal container port to the host). See Ports for details. |
To customize the container's behavior, you can pass environment variables using
the -e parameter in the format <VARIABLE_NAME>=<VALUE>.
| Variable | Description | Default |
|---|---|---|
USER_ID |
ID of the user the application runs as. See User/Group IDs for details. | 1000 |
GROUP_ID |
ID of the group the application runs as. See User/Group IDs for details. | 1000 |
SUP_GROUP_IDS |
Comma-separated list of supplementary group IDs for the application. | (no value) |
UMASK |
Mask controlling permissions for newly created files and folders, specified in octal notation. By default, 0022 ensures files and folders are readable by all but writable only by the owner. See the umask calculator at http://wintelguy.com/umask-calc.pl. |
0022 |
LANG |
Sets the locale, defining the application's language, if supported. Format is language[_territory][.codeset], where language is an ISO 639 language code, territory is an ISO 3166 country code, and codeset is a character set, like UTF-8. For example, Australian English using UTF-8 is en_AU.UTF-8. |
en_US.UTF-8 |
TZ |
TimeZone used by the container. The timezone can also be set by mapping /etc/localtime between the host and the container. |
Etc/UTC |
KEEP_APP_RUNNING |
When set to 1, the application is automatically restarted if it crashes or terminates. |
0 |
APP_NICENESS |
Priority at which the application runs. A niceness value of -20 is the highest, 19 is the lowest and 0 the default. NOTE: A negative niceness (priority increase) requires additional permissions. The container must be run with the Docker option --cap-add=SYS_NICE. |
0 |
INSTALL_PACKAGES |
Space-separated list of packages to install during container startup. List of available packages can be found at https://pkgs.alpinelinux.org. | (no value) |
PACKAGES_MIRROR |
Mirror of the repository to use when installing packages. List of mirrors is available at https://mirrors.alpinelinux.org. | (no value) |
CONTAINER_DEBUG |
When set to 1, enables debug logging. |
0 |
SHARRY_BASE_URL |
The external URL where Sharry can be reached (e.g. https://sharry.example.com). This is used to create absolute URLs and to configure the authentication cookie. These URLs are sent to the client, so they must resolve back to the Sharry server. If "network error" error messages are seen in the browser, then this setting is probably not correct. If the default value is used, the external URL is obtained dynamically by inspecting HTTP headers of the request. |
http://localhost:9090 |
SHARRY_BACKEND_AUTH_FIXED_USER |
Username of the built-in administrator account. Setting this variable to an empty value disables this account. | admin |
SHARRY_BACKEND_AUTH_FIXED_PASSWORD |
Password of the built-in administrator account. Setting this variable to an empty value disables this account. | changeme |
Many tools used to manage Docker containers extract environment variables defined by the Docker image to create or deploy the container.
For example, this behavior is seen in:
- The Docker application on Synology NAS
- The Container Station on QNAP NAS
- Portainer
- etc.
While this is useful for users to adjust environment variable values to suit their needs, keeping all of them can be confusing and even risky.
A good practice is to set or retain only the variables necessary for the container to function as desired in your setup. If a variable is left at its default value, it can be removed. Keep in mind that all environment variables are optional; none are required for the container to start.
Removing unneeded environment variables offers several benefits:
- Prevents retaining variables no longer used by the container. Over time, with image updates, some variables may become obsolete.
- Allows the Docker image to update or fix default values. With image updates, default values may change to address issues or support new features.
- Avoids changes to variables that could disrupt the container's
functionality. Some undocumented variables, like
PATHorENV, are required but not meant to be modified by users, yet container management tools may expose them. - Addresses a bug in Container Station on QNAP and the Docker application on Synology, where variables without values may not be allowed. This behavior is incorrect, as variables without values are valid. Removing unneeded variables prevents deployment issues on these devices.
The following table describes the data volumes used by the container. Volume
mappings are set using the -v parameter with a value in the format
<HOST_DIR>:<CONTAINER_DIR>[:PERMISSIONS].
| Container path | Permissions | Description |
|---|---|---|
/config |
rw | Stores the application's configuration, state, logs, and any files requiring persistency. |
The following table lists the ports used by the container.
When using the default bridge network, ports can be mapped to the host using the
-p parameter with value in the format <HOST_PORT>:<CONTAINER_PORT>. The
internal container port may not be changeable, but you can use any port on the
host side.
See the Docker Docker Container Networking documentation for details.
| Port | Protocol | Mapping to Host | Description |
|---|---|---|---|
| 9090 | TCP | Mandatory | Port used to access the web interface of the application. |
Environment variables, volume mappings, and port mappings are specified when creating the container. To modify these parameters for an existing container, follow these steps:
- Stop the container (if it is running):
docker stop sharry- Remove the container:
docker rm sharry- Recreate and start the container using the
docker runcommand, adjusting parameters as needed.
Note
Since all application data is saved under the /config container folder,
destroying and recreating the container does not result in data loss, and the
application resumes with the same state, provided the /config folder
mapping remains unchanged.
Below is an example docker-compose.yml file for use with
Docker Compose.
Adjust the configuration to suit your needs. Only mandatory settings are included in this example.
services:
sharry:
image: jlesage/sharry
ports:
- "9090:9090"
volumes:
- "/docker/appdata/sharry:/config:rw"Each release of a Docker image is versioned, and each version as its own image tag. Before October 2022, the versioning scheme followed semantic versioning.
Since then, the versioning scheme has shifted to
calendar versioning with the format YY.MM.SEQUENCE,
where:
YYis the zero-padded year (relative to year 2000).MMis the zero-padded month.SEQUENCEis the incremental release number within the month (first release is 1, second is 2, etc).
View all available tags on Docker Hub or check the Releases page for version details.
The Docker image is regularly updated to incorporate new features, fix issues, or integrate newer versions of the containerized application. Several methods can be used to update the Docker image.
If your system provides a built-in method for updating containers, this should be your primary approach.
Alternatively, you can use Watchtower, a container-based solution for automating Docker image updates. Watchtower seamlessly handles updates when a new image is available.
To manually update the Docker image, follow these steps:
- Fetch the latest image:
docker pull jlesage/sharry- Stop the container:
docker stop sharry- Remove the container:
docker rm sharry- Recreate and start the container using the
docker runcommand, with the same parameters used during initial deployment.
For Synology NAS users, follow these steps to update a container image:
- Open the Docker application.
- Click Registry in the left pane.
- In the search bar, type the name of the container (
jlesage/sharry). - Select the image, click Download, and choose the
latesttag. - Wait for the download to complete. A notification will appear once done.
- Click Container in the left pane.
- Select your Sharry container.
- Stop it by clicking Action -> Stop.
- Clear the container by clicking Action -> Reset (or Action -> Clear if you don't have the latest Docker application). This removes the container while keeping its configuration.
- Start the container again by clicking Action -> Start. NOTE: The container may temporarily disappear from the list while it is recreated.
For unRAID users, update a container image with these steps:
- Select the Docker tab.
- Click the Check for Updates button at the bottom of the page.
- Click the apply update link of the container to be updated.
When mapping data volumes (using the -v flag of the docker run command),
permission issues may arise between the host and the container. Files and
folders in a data volume are owned by a user, which may differ from the user
running the application. Depending on permissions, this could prevent the
container from accessing the shared volume.
To avoid this, specify the user the application should run as using the
USER_ID and GROUP_ID environment variables.
To find the appropriate IDs, run the following command on the host for the user owning the data volume:
id <username>This produces output like:
uid=1000(myuser) gid=1000(myuser) groups=1000(myuser),4(adm),24(cdrom),27(sudo),46(plugdev),113(lpadmin)
Use the uid (user ID) and gid (group ID) values to configure the container.
To access the shell of a running container, execute the following command:
docker exec -ti CONTAINER shWhere CONTAINER is the ID or the name of the container used during its
creation.
Assuming that container's ports are mapped to the same host's ports, the interface of the application can be accessed with a web browser at:
http://<HOST IP ADDR>:9090
By default, Sharry comes with a built-in administrator account, with credentials defined by the following environment variables:
| Variable | Description | Default Value |
|---|---|---|
SHARRY_BACKEND_AUTH_FIXED_USER |
Username | admin |
SHARRY_BACKEND_AUTH_FIXED_PASSWORD |
Password | changeme |
This account can be used to login to the web interface of Sharry.
Caution
For security reason, it is strongly recommended to set a strong password. Do not use the default one!
If not needed, this account can be disabled by setting any of these two variables to an empty value.
Sharry configuration can be customized via two methods:
- Environment variables.
- Configuration file.
All configuration parameters supported by Sharry can be consulted at https://eikek.github.io/sharry/doc/configure
The configuration file of Sharry is located at
/config/sharry.conf inside the container. It can be adjusted directly as
needed.
Container environment variables can be used to override values from the config
file. Variable names always start with SHARRY_ and the remainder can be
derived from the corresponding config option by replacing period . and dash
- characters by an underscore _, but excluding the root namespace
sharry.restserver. For example, the config option
sharry.restserver.bind.port would be SHARRY_BIND_PORT as environment
variable. A value given as environment variable has priority.
Tip
A default SHARRY_ environment variable (as defined under the
Environment Variables section) can be ignored by
setting its value to UNSET. This forces the use of the config option value
from the configuration file,
Sharry cannot be exposed directly to the Internet. Features required to allow this is out of scope for Sharry. Instead, it should run behind a reverse proxy. A reverse proxy can offer a secure access via HTTPs to the web interface, while also providing a valid certificate that can be verified by browsers.
See https://eikek.github.io/sharry/doc/reverseproxy for more details.
Having troubles with the container or have questions? Please create a new issue.
For other Dockerized applications, visit https://jlesage.github.io/docker-apps.