Search Results for 'chown'

[Member entropyagent]

Trying antiX21 runit 32bit on another pentium 3 – I compared it to a devuan4 runit 64bit machine.
There do not seem to be ssh logs on the antiX21 machine, but there are on the devuan4 machine
Could this be a sign that the _runit-log id is needed for ssh to create logfiles?

on devuan4runit 64-bit machine:

--:/etc/sv/ssh/log$ grep -i runit-log /etc/passwd 
runit-log:x:999:999:Created by dh-sysuser for runit:/nonexistent:/usr/sbin/nologin
_runit-log:x:998:998:Created by dh-sysuser for runit:/nonexistent:/usr/sbin/nologin
--:/etc/sv/ssh/log$

--:/etc/sv/ssh/log$ cat /etc/sv/ssh/log/run; 
#!/bin/sh
chown _runit-log:adm '/var/log/runit/ssh'
chmod 750 '/var/log/runit/ssh'
exec chpst -u _runit-log svlogd -tt '/var/log/runit/ssh'
--:/etc/sv/ssh/log$ ls -ld /var/log/runit/ssh
drwxr-x--- 2 _runit-log adm 4096 Jun 11 19:20 /var/log/runit/ssh   <---logfolder owned by _runit-log:adm
--:/etc/sv/ssh/log$  sudo ls -lrt /var/log/runit/ssh/ | tail -4
-rw-r--r-- 1 _runit-log _runit-log   363 Jun  3 08:05 @400000006299a691227c50d4.u     <---logfiles owned by _runit-log:_runit-log
-rw-r--r-- 1 _runit-log _runit-log  4051 Jun  5 17:09 @40000000629ce3982e74632c.u
-rw-r--r-- 1 _runit-log _runit-log  5895 Jun 11 09:57 @4000000062a4cee6247fae6c.u
-rw-r--r-- 1 _runit-log _runit-log  2207 Jun 14 09:48 current
--:/etc/sv/ssh/log$ 

on antix21runit machine

--:/etc/sv/ssh/log
$ grep -i runit-log /etc/passwd   <---- No sign of runit-log in passwd
--:/etc/sv/ssh/log

--:/etc/sv/ssh/log
$ cat /etc/sv/ssh/log/run
#!/bin/sh
chown _runit-log:adm '/var/log/runit/ssh'
chmod 750 '/var/log/runit/ssh'
exec chpst -u _runit-log svlogd -tt '/var/log/runit/ssh'
--:/etc/sv/ssh/log
$ ls -ld /var/log/runit/ssh
drwxr-x--- 2 root root 4096 Nov 10  2021 /var/log/runit/ssh     <---logfolder owned by root:root
--:/etc/sv/ssh/log
$ sudo ls -lrt /var/log/runit/ssh/ | tail -4                    
total 0                                                         <---no sign of logfiles
--:/etc/sv/ssh/log
$ 

Hi antiXers

Last year while fumbling though an install of antiX21 64bit runit edition, I encountered this status messages in the output of ps command:

$ ps -feww| grep -i log
root 1505 1 0 21:29 ? 00:00:02 runsvdir -P /etc/service log: log/./run: file does not exist chown: invalid user: ‘_runit-log:adm’ chpst: fatal: unknown user/group: _runit-log 

I still have this error in the antiX21 install from that time:

$ ps -feww|grep -i log
root      1515     1  0 21:07 ?        00:00:01 runsvdir -P /etc/service log: '_runit-log:adm' chpst: fatal: unknown user/group: _runit-log runsv ssh: fatal: unable to start log/./run: file does not exist runsv acpi-support: fatal: unable to start ./run: file does not exist runsv sudo: fatal: unable to start ./run: file does not exist *** debug [daemon/old_main.c(156)]: selected 0 times chown: invalid user: '_runit-log:adm' chpst: fatal: unknown user/group: _runit-log 

I see this seems to have been mentioned during testing of one of the alphas?:
Reply To: antiX-bullseye-a2-runit_x64-full.iso available

I am busy tidying up an install of antiX21 386 runit on a Thinkpad a22m with Pentium 3, and it seems to have the same output in the ps – I am too lazy to try and copy it over, but it also complains about the unknown user/group in the chpst command.

I am wondering if this could be because runit is expecting to be able to change a process owner to id “_runit-log” ?

This id seems to be mentioned in this debian bug report: dh-runit: Change in runit loguser need transition code
Sample text “Runit recently changed the loguser from runit-log to _runit-log”

Could this be a concern?

• This topic was modified 11 months ago by entropyagent.
• This topic was modified 11 months ago by entropyagent.

[Member h2]

You’ll want 3.3.17, 3.3.16 was a point release to rush out nvidia gpu microarchitecture when nvidia announced open sourcing kernel driver for their newer Turing and Ampere and newer microarchitectures, 3.3.17 finishes that and added AMD and Intel, and a lot of other bug fixes, along with a really big internal optimization I’d wanted to do for a while. 3.3.17 also extends the gpu data features to cpu as well, making it fairly complete. I’m being patient on 3.3.17 because 3.3.16 went out so fast, so this one I’m using the time to clean up code, bugs, etc, found and fixed quite a few very long term issues as well, which was nice.

3.3.17 will be out in a few days, unless other glitches or issues pop up. Wnen you run current pinxi, you will be testing it out, and better to find issues before release than after.

First thing I install on a system is pinxi, second thing I do is: chown me:me the file in /usr/local/bin so I can use -U or -U 3 as regular user, or chmod 666 /usr/local/bin/pinxi, either works fine. Then each time I login to test something, I just do pinxi -U or -U 3, depending on what I’m doing. -U 3 isn’t really for users, just people actively testing, so they or I can verify a fix for an issue worked, or isn’t working, or to pop in some debuggers, whatever, -U usually is what you want since that just grabs the latest github pinxi I’ve committed.

3.3.16 also started the process of also opening some backend tools I use for pinxi data, so those aren’t black boxes anymore, but that’s only of interest to developers and the curious.

• This reply was modified 11 months, 1 week ago by h2.
• This reply was modified 11 months, 1 week ago by h2.

inxi system information script (install info) :: inxi git

[Member Robin]

Again a new testing version of desktop menu (3.30) is present at gitlab (downloadlink)

I’ve rethought the way the script behaves.
objectives:
– keep backward compatibility (apt-hook -​-write-out-global called by sudo/root) while allowing multiple user specific configurations at the same time.
– store menus per user instead of one menu design for all.
– make handling more convenient (removed confusing option conflicts)
– clean separation of multiuser and singleuser processing mode.

1.) So I removed the autoconfig option, and made this the default if a user has created his own config file. Otherwise an OS defult config file will be used.

2.) Changed the behaviour of -​-write-out-global to only get accepted when called by sudo/root, since it will write menu globally (for all users). Hence it also rejects any additional command line options, so if this option is filed, merely the respective user specific configs or OS default will get applied, per user home.

3.) Added the -​-write-out-single option, which allows user either to file additional options, or in case no additional options are filed to apply the stored configuration.

4.) Excluded -​-write-out-global and -​-write-out-single from being stored in config file. (maybe some other options need to get excluded also)

5.) Added chown and chmod to build-menu function in order to make sure files are still writable by user if script was run sudoed.

6.) Expects an OS default settings file named “settings” in the /usr/share/desktop-menu folder.
Example for antiX default menu design:

--order=n
--category-filter=n

This was added to allow easy default menu design changes for upcoming antiX versions without need to rewrite the script code itself. If the file is not present a fallback will be added to use some script internal default values instead.

Needed changes in system:
The following symbolic links are to be changed to

/home/<username>/.fluxbox/menu-applications -->  /usr/share/desktop-menu/<username>/.fluxbox/menu-applications
/home/<username>/.icewm/menu-applications -->  /usr/share/desktop-menu/<username>/.icewm/menu-applications
/home/<username>/.jwm/menu-applications -->  /usr/share/desktop-menu/<username>/.jwm/menu-applications

for all users and in /etc/skel in order to make things work.

@translators: Please wait with further translations until transifex resource is updated. Some translatable strings have had to be changed or removed, while most of them are untouched. Some new translatable strings were added.

Here can you see another reason why it is more eligible to split a long text into many small translatable strings instead of keeping it in a single string: If the help text would have been in a single string, all its translations would get removed from transifex completely the moment the updated .pot file is uploaded. Having it split up in several translatable strings allows updating the resource without loosing all the other already translated strings which are part of the help file also and which have not been touched. Sure, we can discuss whether it is better to split into lines, or split into small paragraphs comprising of e.g. one option description. Since some of the individual descriptions are quite long already iteself, I decided to use the lines split method here.

@Dave : New merge request #6 is filed, containing all commits from the #3, #4 and #5 also.

Windows is like a submarine. Open a window and serious problems will start.

[Member Robin]

dugin wrote:

Is this difficulty because I am working with mounting points, rather than devices themselves?

Yes and No. You are supposed to work on mountpoints always, never with the devices found in /dev directly, when it’s about accessing files stored on a device. But yes, in order to manually mount a device you are supposed to mount it directly from its device name present in /dev to a mountpoint (which is actually a simple ordinary empty folder). But the mount command is very flexible, you can even mount a file system living in a file present in a folder of a mounted device to another folder in your file system. You did something similar by mounting the existing mountpoint folder of your already mounted device to a new mountpoint. When mounting something without explicitly specifying a mountpoint antiX defaults to mount it to /media/<username>/<devicename>.

You’ll have to think about your concepts about the way how you try to use linux. Really, it is not meant to use root by default, and it won’t ever work properly (as you have observed already). All the error messages and problems concerning file access you report here are caused by this.

Basically the problem when running a file manager as root is: It’ll start all the programs in root context also when accessing them from within its gui. This is not a good idea for all your tasks. You have posted yourself, that the programs complain about the way you try to work on your PC:

dugin wrote:

root@antix1:/media/sda2# VLC is not supposed to be run as root. Sorry.

Well, it’s your system, and it’s linux, so you are free to do it anyway. (Don’t complain about all the problems rising from doing it anyway, you have been warned)

It is not a good idea to run any filemanager as root by default, this is meant only for rare occasions you have to perform some administrative tasks which can’t get done in another way by ordinary user. And you simply don’t need it.

There are several ways to overcome your problem.
Even if this partition is some TiB of size, you won’t come around to set at least the file permissions straight to be able to work everyday in a sensisble way on files stored on it. This is not a problem, as long you do use it actually for backup purposes occasionally only, in this case you can use actually root file manager to perform the copy actions needed. This task is something you won’t perform every two minutes, and no other programs are involved. But if you want to really work on it (using programs to open/read/write/play files stored on it) this is no good.

First option: change ownership and permissions
Set the ownership of all the files and folders stored on your device to
root:users
using the recursive option as I described some postings above. (I presume your user is member of the group users) If you want to have it set to a more narrowed access use the group with the same name as your user, which he also should be member of.

sudo chown -R root:users /media/sda2/

Then change all the permissions of the files to rw-rw-r– or rw-rw—- (the folders to rwxrwxr– or rwxrwx—

find /media/sda2 -type d -print0 | sudo xargs -0 -r chmod 774
find /media/sda2 -type f -print0 | sudo xargs -0 -r chmod 664

Alternatively you could use 770 (folders) and 660 (files) here instead, to exclude “all” from seeing and reading files at all. Since your user is member of the group to which is granted sufficient permission, this is enough already.

Advantage: This way you don’t need to allow full file access to “all” (=”world”).
I intentionally didn’t use the -R option present in chmod here, since you need to treat directories and files differently:
The execute permission has to be set on folders to be able to rename (or move) files within a folder, otherwise this task will fail in file manager later.

Second option: keep ownership, but change permissions
keep the ownership of the files on your device the way you have it (root:root) and obviously want to keep it. Only change the permissions set on all the files stored straight:

find /media/sda2 -type d -print0 | sudo xargs -0 -r chmod 777
find /media/sda2 -type f -print0 | sudo xargs -0 -r chmod 666

Drawback: The “whole world” gets write access to the files this way. You need it that way, since otherwise your user is excluded from access to the files.

The question must be allowed: If you grant full access to everybody anyway, why do you insist to keep the ownership by root? It’s way more easy to change the ownership than to handle the permissions for files and folders separately: Folders need the execute flag set, files should not have set it by default.

So I would do it that way:

Third option (and in my eyes best soulution, and what I had originally recommended): change ownership only

sudo chown -R user:group /media/sda2/

(replace user and group both by your actual username, or use “users” or “root” for the group, and make sure to use the correct path where your drive is actually mounted to)

Each of these possible solutions will take some time, but it will solve all your trouble. It’s up to you whether you insist on trying to put the cart before the horse. Using programs (including file managers) as root by default enforced by keeping ownership and permissions of files which must be accessed having set in an inappropriate way is exactly what I’d call like that.

I’d recommend you to experiment with the above commands on a test folder containing some test subfolders and files, in which you have set the ownership and permissions exactly the way you have them on your external storage drive. Check the behavior (accessing by programs and file managers without being root) before applying one of the options from above, and check the behaviour afterwards again. Set the ownership back to original before applying another from the above options. Once you have found out what suits you best, let it run on your big external storage.

P.S.: You didn’t read me correctly. I meant the rox internal log console, not a console rox was originally started from. See attached screenshot.

Attachments:

1. 

   05-Rox-filer-log-console.jpg
   

Windows is like a submarine. Open a window and serious problems will start.

[Forum Admin Dave]

@Robin, please see here for gitlab https://gitlab.com/antiX-Dave/desktop-menu-antix. For the main antiX version https://gitlab.com/antiX-Linux/desktop-menu-antix
My gitlab has an updated version of desktop-menu that includes the changes you tested from BobC (–comments) as well as a slightly different way to changing the text order (–order=ngc). Hopefully this has a faster execution time for you. It also defaults to using the program names, but if you specify –generic-names or –comments it will switch to either or both. However if you want to keep the program names then you will need to also add the –names option. When using multiple options it is best to specify an order otherwise the default output would be messy.

As to setting the menu-applications file on a per user basis.
Using a symlink specific to each user (which should probably reside in /var/cache/desktop-menu/?) would not really be any different than editing the user ~/.*/menu-applications files directly. Other than the user can “ignore” the automatic updates by removing the symlink. Idealistically for a per user symlink setup, desktop-menu would check for files that it could update in a specific location and update them using the apt hook. Then the user (via manually removing the symlink and target or through an app) could enable and disable automatic updates on a per user per window manager basis.

Maybe, does this work?

su
mkdir -p /var/cache/desktop-menu/
chown root:users /var/cache/desktop-menu/
chmod 770 /var/cache/desktop-menu/
exit
mkdir -p /var/cache/desktop-menu/<code>whoami</code>/.fluxbox/
touch /var/cache/desktop-menu/<code>whoami</code>/.fluxbox/menu-applications
ln -s /var/cache/desktop-menu/<code>whoami</code>/.fluxbox/menu-applications ~/.fluxbox/menu-applications.
desktop-menu --write-out 

Then if it does, does it follow the user’s translation?
If so the apt hook can crawl /var/cache/desktop-menu/ for valid users (assumed by name in the base desktop-menu dir) and execute su username -c desktop-menu --write-out.
Then simply removing the user’s folder from /var/cache/desktop-menu/ would stop the update for that user without needing a config file.

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

[Member Robin]

dugin wrote:

that info would go a long way to understanding the problem, and/or finding a good workaround.

So try to catch the error. You followed the right path already, starting the thing in a terminal window. You said, rox blocks the terminal once started from it, so try add an & to the command starting rox in console, to let it run as a coproces.

Moreover, did you notice RoxFiler comes with a log console? You can live see whether the change of permissions was actually performed.
Right-click, from Context Menu choose “Window → Show Log”.

Then change the permissions of a folder or file, don’t forget to press “Actualise” once you have set the checkboxes as you want them. The file change date in the properties window of the file should change immediately to the actual time and date values, and there should be an entry in the log: Change permissions /path/to/file

A second and more sophisticated way to change the permissions in Roxfiler is to chose “permissions” from context menu (instead of properties). There you get a field to chose the permission changes in symbolic mode from a predefined list, but you can enter them simply manually there, Symbolic and Numeric styls both (e.g. 755, or all other variants chmod understands)

Check what the Log console tells you once you change permission of files and folders.

For testing (wanted to explore the new RoxFiler anyway) I have set up a folder the same way as you described, having it stored on an external drive (USB plugged external hdd, but it is ext4 format, shouldn’t make a difference here), mounted with the very flags and permissions you have posted in your command line output of the mount command. Then I’ve created a new folder on it, changed the ownership of this folder to “root:root” on console using chown, and changed also the permission to 755 just like your folder is set (drwxr-xr-x). Then I started »roxfiler as root« from antiX menu, entered the folder and was perfectly able to create a new file »new-testfile-owned-by-root« within this folder, simply by right clicking and chosing »new → empty file« from context menu. Then, again from context menu, after clicking this file, choosing “open with geany”, a second instance of geany comes up (since I have running a first one by the true user account already), the new geany instance was started in root context obviously, since I can edit the file, and save it without any error. I can’t reproduce the problem you describe.

So probably best would be: check the internal log console of rox filer as described in the beginning. Maybe there you’ll find something useful for tracing down the issue.

Windows is like a submarine. Open a window and serious problems will start.

[Member Robin]

1.) The output of mount command you’ve posted looks fine to me. Your partition is mounted read write (you see the rw flag in the line; in case it was only readable this would have been an r instead)

Do all the files and folders on this external drive belong to you? Is it a data vault only, or does the partition contain an operating system also (in this case you need to be way more carefully when taking over the ownership.)

2.) Old folders when created by another old linux system tend to have set different ownership (user-id) to the folders. You can set this straight simply by using the chown command on console with its recursive option. Then the ownership of all the folders and files will be set to the desired user.

sudo chown -R user:group /media/sda2/

Don’t forget to replace user and group both by your actual user name, separated by a colon (e.g. demo:demo ).

But let me emphasise Brians restriction:

Brian Masinick wrote:

IF you are the actual owner of this file and it’s not something shared on a multi-user computer,

Only do this in case you are actualy sure there is nothing stored on it which doesn’t belong to you or is needed to keep its root ownership.

Windows is like a submarine. Open a window and serious problems will start.

[Forum Admin Dave]

I do not know if this has ever worked since I originally updated the script.

The reason; From conversation with BobC slightly before you had noticed this.

The menu is automatically updated through an apt hook.
This is done in a system wide configuration and it is done as the root user affecting all users by default as the user files are symlinked to there. Originally when I had updated this to include an apt hook I did not think the menu should have a refresh button (Well I did, but commented out). I am not certain if the current “Refresh menu” menu entry actually does anything. This is because it cannot overwrite the symlink and the original menu files which it points to are owned by root and unwritable to the user. Being a system wide file it cannot really be controlled by a user configuration under ~/.desktop-menu/desktop-menu.conf. One of the unwritten rules is not to modify the user configuration files directly. Therefor altering the main ~/.wm/menu file or ~/.wm/menu-applications via script was a no no (and alot of people at the time complained that manually editing the menu file was not set as default anymore). This is why the apt hook does not edit the users file directly and a symlink is used.

IMHO, making a configuration file for these options is not really any different than altering the menu file directly. When I had originally made the modification to allow an automatically updated menu I thought the “Refresh menu” entry should be commented out and uncommented if the user would like a different application menu than default.

You may be able to get around the permission issue by making the files symlinked to have “user” as the primary group with read and write permissions. Try as root:

chown root:users /usr/share/desktop-menu/.*/menu-applications
chmod 664 /usr/share/desktop-menu/.*/menu-applications

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

I recently discovered the joys of using a shared folder to move files between my computers. It was a pain to set the shared folder because I did not find, in the repository any GUI that I was able to use to configure samba. I did eventually find a real nice GUI (not yet available in the repository), but, what really allowed me to first configure and use a network shared folder was the excellent YouTube channel “learnlinux.tv”. I jotted down a few notes that I used to create this “How to”. Following it will allow anyone to create a network shared public folder.

How to create a public shared folder on your local network:
(Adapted from https://www.learnlinux.tv/setting-up-simple-samba-file-shares/)

1-Install samba with all it’s dependencies, Open a terminal and run this commands, enter your password if asked to:
sudo apt update && sudo apt install samba

2- Make sure samba is not being executed, on the terminal, run this command:
sudo service smbd stop

and then back up the default Samba configuration, just to be on the safe side (optional step)
sudo mv /etc/samba/smb.conf /etc/samba/smb.confBAK

3- Open samba configuration file for edition:
sudo geany /etc/samba/smb.conf

4- Edit the smb.conf file:
Delete any of the file’s contents and replace it with the text below, making sure that you replace the capitalized text with the appropriate values. FILESERVER and WORKGROUP do not have to be replaced, unless you what to and SHARED-FOLDER can/should be replaced with the name of the folder you want to be displayed (do not use spaces or special characters). The only value you have to adapt when editing this config file is /FULL/PATH/OF/FOLDER/TO/BE/SHARED that has to be replaced with the full path of the folder you want to be shared: for example- /home/ppc/PublicFiles
Optionally you can also replace the smbuser and smbgroup values with any values you select, but you’ll have to apply those exact values on the terminal commands that you’ll have to enter after editing the smb.conf file…

[global]
server string = FILESERVER
workgroup = WORKGROUP
security = user
map to guest = Bad User
name resolve order = bcast host

[SHARED-FOLDER]
path = /FULL/PATH/OF/FOLDER/TO/BE/SHARED
force user = smbuser
force group = smbgroup
create mask = 0664
force create mode = 0664
directory mask = 0775
force directory mode = 0775
public = yes
writable = yes

5- Save the config file and close geany and, on the terminal run this commands to create the required and group and user:

sudo groupadd --system smbgroup
sudo useradd --system --no-create-home --group smbgroup -s /bin/false smbuser

IMPORTANT: make really sure that the folder you what to share already exists and DO NOT SHARE YOUR HOME FOLDER!!! (but you can share any sub-folder inside your home- example: /home/ppc/downloads

6- Change ownership/permissions of the shared folder (replace /FULL/PATH/OF/FOLDER/TO/BE/SHARED with the appropriate address to your shared folder):
sudo chown -R smbuser:smbgroup /FULL/PATH/OF/FOLDER/TO/BE/SHARED
sudo chmod -R g+w /FULL/PATH/OF/FOLDER/TO/BE/SHARED

7- Make sure that samba is started:
sudo service smbd restart

That’s all.

How to access your shared folder from another device connected to your network:
You can now access your shared folder from any other computer connected to the same local network by entering, on the address bar of your file manager:
//IP.of.host.computer/SHARED-FOLDER
(replacing, of course, the “IP.of.host.computer” part with the real IP of the computer that is sharing the folder(s) and “SHARED-FOLDER” with the name you choose, for example //192.123.4.5/PublicFolder
How do you get the IP of the computer that is hosting the shared file? On that computer open the terminal and run this command:
ifconfig
On the line just below you network connection (ex: “eth0” if you are using a network cable or “wlan0” if you are using wi-fi) is a line staring with “inet”- the long string of four numbers separated by dots- that’s the IP you want.

Extra tip- sharing more folders/sharing protected folders:

You can add as many shared folders as you want, to the smb.conf file, taking care to remember to:
-always disable samba before editing the config file:
sudo service smbd stop

-edit the samba config file, adding and adapting the [SHARED-FOLDER] part included above. If you want to make it so the users accessing your shared folder can’t change it, make sure to change the last line “writable = yes” to “writable = no”:

Example:
[PROTECTED-SHARED-FOLDER]
path = /FULL/PATH/OF/FOLDER/TO/BE/SHARED/NUMBER/2
force user = smbuser
force group = smbgroup
create mask = 0664
force create mode = 0664
directory mask = 0775
force directory mode = 0775
public = yes
writable = no

-Save your editions to the config file
-Don’t forget to change ownership of the newly shared folder(s), adapting the commands from step 6.
-Restart samba:
sudo service smbd restart

Troubleshooting:
-Don’t forget- you are sharing the folder over your local network. You can’t access a shared folder over the internet (well, there are ways to do it, but it’s DANGEROUS. If you want to access your local files via the Internet, you’ll be better off using FTP)
-You can’t obviously access a shared folder if the device that hosts the shared folder is off or off-line… If the host of the shared folder is on-line but you can’t access the shared folder, make sure to run (on the host computer);
sudo service smbd restart
-Some File Managers get “frozen” if they lose connection to a mounted shared folder – zzzfm is one of such file manager- if that happens you’ll either have to re-enable the shared folder on the host computer and then unmount it on the remote computer or you’ll have to kill zzzfm and forcibly unmount the mount point… Yeah… it’s not pretty… You’ll have to force zzzfm to “let it go, let it go” (yes, it’s a “Frozen” joke)

P.

• This topic was modified 1 year, 1 month ago by PPC.
• This topic was modified 1 year, 1 month ago by PPC.
• This topic was modified 1 year, 1 month ago by PPC.

[Member madibi]

@davidecafe
prima ho supposto, ma ora sono certo che se vedi tutto con i diritti di admin, per evitare di “fare giri lunghi”, devi mettere a posto le questioni dei diritti.
bisogna utilizzare chown in modo ricorsivo.

Ci sono ragioni specifiche per cui eviti quel passaggio?

@davidecafe
before I only supposed, now I am certain that if with admin rights you can see everything, to avoid “doing long laps”, you have to settle the issues of rights.
you have to use the chown command in recursive way.

Are there any specific reasons why you avoid that step?

[Member madibi]

qualche info in più non sarebbe male. Ipotizzo che l’istallazione sia di antix 21 full, 64 bit.
Il primo tentativo che farei, da “dentro”, proverei cosa mi dice gparted su sda5, come secondo tentativo proverei zzzfm (se 21) o spacefm (se 19 o prima) con i poteri root (ad es: sudo zzzfm) e vedere se la monta.
La cosa strana, rispetto al mio sistema, è che dati è dentro /media/root/dati
la domanda è a chi appartiene? a davidecaffe oppure a root?
è possibile che la soluzione consista solo in un comando chown (change owner = cambia proprietario) dato in modo ricorsivo.
Fammi sapere
m

[Member sybok]

Hi,

the combination with find + exec can be used to block change ownership and/or group from terminal, e.g.

find /home/sybok/ -name '*' -type d -exec chown sybok {} -- \;
find /home/sybok/ -name '*' -type d -exec chgrp sybok {} -- \;

The same can be achieved with ‘-R’ in each of the two commands with less types
chown sybok -R /home/sybok/

• This reply was modified 1 year, 2 months ago by sybok.

[Moderator christophe]

It sounds to me like root wrote files to sdc1, and “he” now owns those files. If it were me, and I simply wanted to change ownership back to Roland, I would do what madibi suggested – chown recursively on /media/sdc1.
Though I’m sure sybok’s diagnostics would be very valuable.

confirmed antiX frugaler, since 2019

[Member madibi]

Hi Roland!
From where did you copied the 4000 files?
If I understand correctly your images, the owner of the hd is root.
So the best for you is to learn how to use the command “chown” = change owner, in a recursive way, so that all the hd and sub directories will be owned by you.

Another way to arrive to the very same result, is to open the /media/DISKINQUESTION/ with zzzfm with the root rights and change the owner (remember, always in a recursive way).

Please let me know 🙂
m