Search Results for 'chown'

[Forum Admin Dave]

If this setup is for building / testing webpages then the easiest would be to make the folder with www-data:users ownership

chown www-data:users /var/www/html
chmod -R 664 /var/www/html/

If it is only for your user, add a directory to your home directoy like ~/Web-tests, make the ownership your-username:www-data, and change /etc/apache2/sites-enables/000-default document root to /home/your-username/Web-tests/ followed by an apache restart (service apache2 restart).

• This reply was modified 1 year, 11 months ago by Dave.

Computers are like air conditioners. They work fine until you start opening Windows. ~Author Unknown

[Member roland]

The suggested chown has restored the permissions to what they should be however have produced another mystery that I do not understand. I installed 4 identical and brand new 500gb disk drives in this build. At first boot it became apparent they came already formatted as Vfat with names in chinese characters which I did not want. I therefore before the installer ran, removed these with Gparted and replaced them as follows:-

drive 0 – sda1 for antiX, sda5 for swap, sda6 for $HOME and sda7 for data
drive 1 – sdb1 for data, sdb2 for data
drive 2 – sdc1 for data, sdc2 for data
drive 3 – sdd1 for data, sdd2 for data

Disk manager then produced a list of drive labels saying that no drives could be found corresponding to these labels, and inviting me to delete the labels if I wished and which was recommended, I did so.

I took advantage of the facility in 19.3 to install antiX on a dedicated partition sda1, swap on sda5, $HOME on sda6 and data on the remaining volumes.

But Gparted finds another partition and I do not know where it is located, 100mb and which Gparted cannot read, producing i-o errors. It is not visible on the maps of sda sdb sdc or sdd. It is causing no trouble except slows up the load of Gparted considerably and the warning messages have to be repeatedly cancelled, but strictly speaking I have no reason to run Gparted now the build is complete. However I would like to be rid of it after discovering the reason why it appears. I wonder if it has a real existence? I don’t suppose it could be the extended partition containing sda5 sda6 and sda7?

I’m sorry this post is drifting away from the original Asunder topic which I feel is secondary to resolving this mystery. I hope I am not stretching the rule too much?

Attachments:

1. 

   asunder_rogue_partition.jpg
   

2. 

   sda1_sda5_sda6_sda7.jpg
   

[Anonymous]

‘roland’ (my $home user folder) has ‘root’ ownership

screenshot shows a directory pathed at /media/roland
but
your $HOME directory is probably elsewhere ( /home/roland )
To confirm this, at commandline you can type: echo $HOME

So, yes, the way forward will be to “fix” the permissions of the media subdirectory.
sudo chown -R roland:roland /media/roland

[Member roland]

Thanks Skidoo, I looked at the permissions for every folder in /media and find to my surprise that the folder ‘roland’ (my $home user folder) has ‘root’ ownership whereas all other partition folders have ‘roland’ ownership. This is a recent install, but I have no recollection of having any event during the install process or since that would have caused me to change the ownership. This ownership must I believe have been conferred by the installer or at least at install time.

I have not yet run a chown to rectify matters until I have put the situation before you and request your comments.

Thanks again for your input.

Attachments:

1. 

   media_permissions.jpg
   

I have created a new user on the live system of Core, using the following command:

useradd -m -g users bob -s /bin/bash

However after running the cli-installer I end up with these permissions on that /home directory:

# ls -l /home
total 4
drwxr-xr-x 4 1000 1000 4096 May  6 05:29 bob

But I would expect to see:

drwxr-xr-x 4 bob users 4096 May  6 05:29 bob

After I manually correct that with:

chown -R bob:users /home/bob

ssh then starts working correctly.

Just wondering am I creating the user wrong?

thanks!

[Anonymous]

strange note – I have the same version on my home and work desktops. Both are antiX 19.3 64 bits…
In my work pc the “show bookmarks” and Tools > “New command” show up translated, but not in my home pc (I don’t recall manually editing those entries in my work pc…)

[..]

how to re-create an equivalent testing environment

Instead of just apt-installing each new version, it’s advisable to first purge the previously-installed packages AND “sudo updatedb && locate zzzfm” to ensure no stale copies of files were left on the system. Without this check, you might neglect to “rm -rf ~/.config/zzzfm” (which the purge operation does not disturb). To avoid (re)typing, You can paste the series of commands into a l’il script.

edited to add:
To (re)test the first-run behavior of the AsRoot zzzfm window, need to also remove pre-existing root files:
“sudo rm -rf /root/.config/zzzfm”

The fact that devices are not showing on the left makes it also consistent view with Root Window, while in SpaceFM Root Window view is not consistent with the default user window, as it looks like zzzFM view.

>>> in SpaceFM Root Window view is not consistent with the default user window

Hold on, IMO the spacefm first-time-run “AsRoot” behavior was, already, correct / desirable. From my perspective, having an AsRoot window which looks comparatively different (even to a jarring extent) first-time-run “AsRoot” is a “GoodThing”. I’m startled to realize that as a side-effect of pre-populating /etc/xdg (and winding up with “consistency”)… we’ve created a “footgun”. The user can (betcha will!) unset the “annoying red colorbar” and will subsequently lose track of “hmm, is this a ‘Root’ file manager instance?” unless/until visually distinct (different) gtk desktop theme is applied via “sudo lxappearance”.

Oh well. The default red colorbar exists for good reason.
“Custom command #1”
? ? ?
label: “Help! Fix my broke.”
scripted action: “cd ~ && chown -R iwannapony:iwannapony”

as soon as I switch desktop to Space-IceWM the drag issue is there. My conjecture is that it is because with Space-IceWM it is SpaceFM that plays role. How can I replace Space-IceWM with zzz-IceWM?

reposting a snippet from post#1 in this topic:

If you would like to use zzzfm to manage desktop icons
(ala ‘space-rox’ desktop sessiontype), you can:

sudo mv /usr/bin/spacefm /usr/bin/spacefm_REAL
sudo ln /usr/bin/zzzfm /usr/bin/spacefm

then logout, choose a space-* sessiontype, login
(or switch via the desktop “Other Desktops” menu entries)

[Member Xecure]

Brian Masinick wrote:

If the code is inherited though it’s easier to simply add the user instead of having to modify code from an outside source every time an update occurs; this invites repeated maintenance and code regression potential.

I completely agree. Once a decision is made to fix the future antix-runit releases, I will follow it. For now I am informing on the reason of the problem.

An example of what I am talking about. This is /etc/sv/connman/log/run current content:

#!/bin/sh
set -e

NAME=connman
LOG="/var/log/runit/$NAME"

test -d "$LOG" || mkdir "$LOG" && chown -R _runit-log:adm "$LOG"
exec chpst -u _runit-log svlogd -tt "$LOG"

If no new users are created for future versions, the change without a specific user launching the svlogd program would look like this:

#!/bin/sh
set -e

NAME=connman
LOG="/var/log/runit/$NAME"

test -d "$LOG" || mkdir "$LOG"
exec chpst svlogd -tt "$LOG"

Though this is not needed for all services. Some of them, like elogind, has this log/run instructions:

#!/bin/sh

exec logger -p daemon.notice -t runsv-elogind

It is best we can get some input from the developers, so that the small gui-script I am building can follow the same decision.

Attachments:

1. 

   Runit-service-manager.png
   

antiX Live system enthusiast.
General Live Boot Parameters for antiX.

[Moderator Brian Masinick]

Xecure wrote:

The reason why logs don’t work as expected is related to how the log “runs”. It requires the existence of a user named “_runit-log”, but this user doesn’t exists in /etc/passwd

If the log script changes to NOT use the _runit-log user, the logs work as expected.

Was there a part of the runit installer that should create this new _runit-log user? Is this user needed?

SO, the solution is editing all log/run files to NOT launch (or chown the log directory) OR creating a new _runit-log user (which should be able to run svlogd.

Which is best?

How about adding the log/run files to a group with sufficient access or add a group that has the necessary access?

This could also solve the problem; depends on which mechanism is preferred for configuration and setup. Adding a runit-log username is fine too. I personally have no preference.

If the code is inherited though it’s easier to simply add the user instead of having to modify code from an outside source every time an update occurs; this invites repeated maintenance and code regression potential.

• This reply was modified 2 years ago by Brian Masinick.

--
Brian Masinick

[Member Xecure]

The reason why logs don’t work as expected is related to how the log “runs”. It requires the existence of a user named “_runit-log”, but this user doesn’t exists in /etc/passwd

If the log script changes to NOT use the _runit-log user, the logs work as expected.

Was there a part of the runit installer that should create this new _runit-log user? Is this user needed?

SO, the solution is editing all log/run files to NOT launch (or chown the log directory) OR creating a new _runit-log user (which should be able to run svlogd.

Which is best?

antiX Live system enthusiast.
General Live Boot Parameters for antiX.

[Member Xecure]

Maybe the error reported in htop may be related (something related to runit trying to access a file/folder but doesn’t have the correct permissions)

Xecure wrote:

runsvdir -P /etc/service log: _runit-log:adm’ chown: invalid user: ‘runit-log:adm’ chpst: fatal: unknown user/group: _runit-log chpst: fatal: unknown user/group: _runit-log chpst: fatal: unknown user/group: _runit-log chpst: fatal: unknown user/group: _runit-log chmod: cannot access ‘/var/log/runit/acpid/*’: No such file or directory chpst: fatal: unknown user/group: _runit-log chpst: fatal: unknown user/group: runit-log

We can see runit-log trying to do something, but it doesn’t have permissions (or cannot figure out how to write there).

I was hoping this could help figure out the problem, but I am no expert. I still think figuring this out is resolving an extra bug, just to make runit even more stable.

• This reply was modified 2 years ago by Xecure.

antiX Live system enthusiast.
General Live Boot Parameters for antiX.

[Member Xecure]

I cannot seem to find the way to stop all the runsv logging.
I see that iotop shows processes like
runsv acpi-support
that when I check the sv status, it says they are down. SO something is calling them and keeps writing who know what, probably a log, but I cannot figure it out at all.
When checking htop (trying to figure out what are the processes with “log” in their name), I can see a process that says:

runsvdir -P /etc/service log: _runit-log:adm’ chown: invalid user: ‘runit-log:adm’ chpst: fatal: unknown user/group: _runit-log chpst: fatal: unknown user/group: _runit-log chpst: fatal: unknown user/group: _runit-log chpst: fatal: unknown user/group: _runit-log chmod: cannot access ‘/var/log/runit/acpid/*’: No such file or directory chpst: fatal: unknown user/group: _runit-log chpst: fatal: unknown user/group: runit-log

Which seems to be related to the runsvdir log, but I cannot find what files are being continually written. I am not sure if this is related or not to the current problem.
When I do
sudo lsof | grep "runsv" > runsv-opened.txt
I can see all files related to runsv that are currently open (if I am not mistaken on how lsof works). But this also doesn’t help e figure out how to disable the log or figure out why services that are down are still being written to.

I will explore on a live-sub tomorrow to see if things are different in live compared to installed.

antiX Live system enthusiast.
General Live Boot Parameters for antiX.

[Member ModdIt]

Hi redrooster, Below should work, I do not know a practical tool with gui.

To make an ISO from your stick and create a file named “bootableusb.iso” Example in your current working directory.
$ sudo dd if=/dev/sdc of=bootableusb.iso
Replace c in device path with your own drive letter

After your iso is created you will also have to do
$ sudo chown $USER:$USER bootableusb.iso
as the iso image will be owned by root due sudo usage.

[Anonymous]

@stephenbb, clicky https://www.antixforum.com/forums/search/chown/ and read the first 2 posts (one posted by Dave, another posted by skidoo).

[Forum Admin Dave]

Askic wrote:

What about to use antiX live CD and use GParted tool to delete /home partition and recreate it as extended? Then I could create a new logical partition of 2 GB for swap. Since /home would be destroyed, antiX reinstall is necessary?

That is a valid option.

You would then need to make a directory with your username in the new /home, copy the contents of /etc/skel/ to /home/username/, then change ownership of the new /home/username/ and contents to your username. You may be better to do the copying on your installed system after making the new /home partition.

As root

mkdir /home/my-username/
cp /etc/skel/* /home/my-username/
chown -R my-username:my-username /home/my-username

Have you tried shrinking the windows partition more?
It seems like you are not using much space in that partition.

Computers are like air conditioners. They work fine until you start opening Windows. ~Author Unknown

[Anonymous]

You can use the following to check whether any files within your home directory are not “owned by” you
cd ~ && find . \! -user $USER
and (after pondering how their ownership got hijacked) you can reclaim ownership via
cd ~ && chown -R $USER:$USER *

Here’s a scenario which may explain the “how”:

While running a program with elevated permissions, the user clicks a toolbar “Help” button and the program retrieves+displays online html helpdocs (or the program otherwise attempts to xdg-open an html document). Even if the web browser recognizes/blocks “no, cannot run as root” and refuses to render the requested document… during the operation, the ownership of any “touched by root” config files may be altered.