file sharing – Sick Gaming

Nextcloud is a software suite for storing and syncing your data across multiple devices. You can learn more about Nextcloud Server’s features from https://github.com/nextcloud/server.

This article demonstrates how to build a personal cloud using Fedora and Nextcloud in a few simple steps. For this tutorial you will need a dedicated computer or a virtual machine running Fedora 31 server edition and an internet connection.

Step 1: Configure the server

Start by updating your system and rebooting:

$ sudo -i
# dnf upgrade
# reboot

Next, disable SELinux by changing enforcing to disabled in /etc/selinux/config and then rebooting to activate the new setting:

# vi /etc/selinux/config
# reboot

If you don’t want to reboot right away, you can use the setenforce command to disable SELinux in the current session.

# setenforce 0

Alternatively, you can follow the directions here to configure SELinux to work with Nextcloud.

Step 2: Install the prerequisites

Before installing and configuring Nextcloud, a few prerequisites must be satisfied.

First, install Apache web server:

# dnf install httpd

Next, install PHP and some additional modules. Make sure that the PHP version being installed meets Nextcloud’s requirements:

# dnf install php php-gd php-mbstring php-intl php-pecl-apcu php-mysqlnd php-pecl-redis php-opcache php-imagick php-zip php-process

After PHP is installed enable and start the Apache web server:

# systemctl enable --now httpd

Next, allow HTTP traffic through the firewall:

# firewall-cmd --permanent --add-service=http
# firewall-cmd --reload

Next, install the MariaDB server and client:

# dnf install mariadb mariadb-server

Then enable and start the MariaDB server:

# systemctl enable --now mariadb

Now that MariaDB is running on your server, you can run the mysql_secure_installation command to secure it:

# mysql_secure_installation NOTE: RUNNING ALL PARTS OF THIS SCRIPT IS RECOMMENDED FOR ALL MariaDB SERVERS IN PRODUCTION USE! PLEASE READ EACH STEP CAREFULLY! In order to log into MariaDB to secure it, we'll need the
current password for the root user. If you've just installed
MariaDB, and you haven't set the root password yet, the password
will be blank, so you should just press enter here. Enter current password for root (enter for none): <ENTER>
OK, successfully used password, moving on... Setting the root password ensures that nobody can log into
the MariaDB root user without the proper authorization. Set root password? [Y/n] <ENTER>
New password: Your_Password_Here
Re-enter new password: Your_Password_Here Password updated successfully! Reloading privilege tables... ... Success! By default, a MariaDB installation has an anonymous user,
allowing anyone to log into MariaDB without having to have
a user account created for them. This is intended only for
testing, and to make the installation go a bit smoother. You
should remove them before moving into a production environment. Remove anonymous users? [Y/n] <ENTER> ... Success! Normally, root should only be allowed to connect from 'localhost'. This ensures that someone cannot guess at the
root password from the network. Disallow root login remotely? [Y/n] <ENTER> ... Success! By default, MariaDB comes with a database named 'test' that
anyone can access. This is also intended only for testing, and
should be removed before moving into a production environment. Remove test database and access to it? [Y/n] <ENTER> - Dropping test database... ... Success! - Removing privileges on test database... ... Success! Reloading the privilege tables will ensure that all changes
made so far will take effect immediately. Reload privilege tables now? [Y/n] <ENTER> ... Success! Cleaning up... All done! If you've completed all of the above steps, your
MariaDB installation should now be secure. Thanks for using MariaDB!

Step 3: Install Nextcloud Server

Now that the prerequisites for your Nextcloud installation have been satisfied, download and unzip the Nextcloud archive:

# wget https://download.nextcloud.com/server/releases/nextcloud-17.0.2.zip
# unzip nextcloud-17.0.2.zip -d /var/www/html/

Next, create a data folder and grant Apache read and write access to the nextcloud directory tree:

# mkdir /var/www/html/nextcloud/data
# chown -R apache:apache /var/www/html/nextcloud

Next, create a dedicated user and database for your Nextcloud instance:

# mysql -p
> create database nextcloud;
> create user 'nc_admin'@'localhost' identified by 'SeCrEt';
> grant all privileges on nextcloud.* to 'nc_admin'@'localhost';
> flush privileges;
> exit;

Step 4: Configure Nextcloud

Nextcloud can be configured using its web interface or from the command line.

Using the web interface

From your favorite browser, access http://your_server_ip/nextcloud and fill the fields:

Using the command line

From the command line, just enter the following, substituting the values you used when you created a dedicated Nextcloud user in MariaDB earlier:

# sudo -u apache php occ maintenance:install --data-dir /var/www/html/nextcloud/data/ --database "mysql" --database-name "nextcloud" --database-user "nc_admin" --database-pass "DB_SeCuRe_PaSsWoRd" --admin-user "admin" --admin-pass "Admin_SeCuRe_PaSsWoRd"

Final Notes

I used the http protocol, but Nextcloud also works over https. I might write a follow-up about securing Nextcloud in a future article.
I disabled SELinux, but your server will be more secure if you configure it.
The recommend PHP memory limit for Nextcloud is 512M. To change it, edit the memory_limit variable in the /etc/php.ini configuration file and restart your httpd service.
By default, the web interface can only be accessed using the http://localhost/ URL. If you want to allow access using other domain names, you can do so by editing the /var/www/html/nextcloud/config/config.php file. The * character can be used to bypass the domain name restriction and allow the use of any URL that resolves to one of your server’s IP addresses.

'trusted_domains' => array ( 0 => 'localhost', 1 => '*', ),

A previous article covered some basics about file permissions on your Fedora system. This installment shows you additional ways to use permissions to manage file access and sharing. It also builds on the knowledge and examples in the previous article, so if you haven’t read that one, do check it out.

Symbolic and octal

In the previous article you saw how there are three distinct permission sets for a file. The user that owns the file has a set, members of the group that owns the file has a set, and then a final set is for everyone else. These permissions are expressed on screen in a long listing (ls -l) using symbolic mode.

Each set has r, w, and x entries for whether a particular user (owner, group member, or other) can read, write, or execute that file. But there’s another way to express these permissions: in octal mode.

You’re used to the decimal numbering system, which has ten distinct values (0 through 9). The octal system, on the other hand, has eight distinct values (0 through 7). In the case of permissions, octal is used as a shorthand to show the value of the r, w, and x fields. Think of each field as having a value:

r = 4
w = 2
x = 1

Now you can express any combination with a single octal value. For instance, read and write permission, but no execute permission, would have a value of 6. Read and execute permission only would have a value of 5. A file’s rwxr-xr-x symbolic permission has an octal value of 755.

You can use octal values to set file permissions with the chmod command similarly to symbolic values. The following two commands set the same permissions on a file:

chmod u=rw,g=r,o=r myfile1
chmod 644 myfile1

Special permission bits

There are several special permission bits also available on a file. These are called setuid (or suid), setgid (or sgid), and the sticky bit (or delete inhibit). Think of this as yet another set of octal values:

setuid = 4
setgid = 2
sticky = 1

The setuid bit is ignored unless the file is executable. If that’s the case, the file (presumably an app or a script) runs as if it were launched by the user who owns the file. A good example of setuid is the /bin/passwd utility, which allows a user to set or change passwords. This utility must be able to write to files no user should be allowed to change. Therefore it is carefully written, owned by the root user, and has a setuid bit so it can alter the password related files.

The setgid bit works similarly for executable files. The file will run with the permissions of the group that owns it. However, setgid also has an additional use for directories. If a file is created in a directory with setgid permission, the group owner for the file will be set to the group owner of the directory.

Finally, the sticky bit, while ignored for files, is useful for directories. The sticky bit set on a directory will prevent a user from deleting files in that directory owned by other users.

The way to set these bits with chmod in octal mode is to add a value prefix, such as 4755 to add setuid to an executable file. In symbolic mode, the u and g can be used to set or remove setuid and setgid, such as u+s,g+s. The sticky bit is set using o+t. (Other combinations, like o+s or u+t, are meaningless and ignored.)

Sharing and special permissions

Recall the example from the previous article concerning a finance team that needs to share files. As you can imagine, the special permission bits help to solve their problem even more effectively. The original solution simply made a directory the whole group could write to:

drwxrwx---. 2 root finance 4096 Jul 6 15:35 finance

One problem with this directory is that users dwayne and jill, who are both members of the finance group, can delete each other’s files. That’s not optimal for a shared space. It might be useful in some situations, but probably not when dealing with financial records!

Another problem is that files in this directory may not be truly shared, because they will be owned by the default groups of dwayne and jill — most likely the user private groups also named dwayne and jill.

A better way to solve this is to set both setgid and the sticky bit on the folder. This will do two things — cause files created in the folder to be owned by the finance group automatically, and prevent dwayne and jill from deleting each other’s files. Either of these commands will work:

sudo chmod 3770 finance
sudo chmod u+rwx,g+rwxs,o+t finance

The long listing for the file now shows the new special permissions applied. The sticky bit appears as T and not t because the folder is not searchable for users outside the finance group.

drwxrws--T. 2 root finance 4096 Jul 6 15:35 finance