When core shell stops outputting lines is the command still running in the background?

[eewiz]

chmod -R 777 pool, when issued from within the pool directory, outputs a line for each file or directory changed.
For commands like this chmod example that echo many lines of data, the shell just stops outputting lines of data after a few minutes.

When this happens, is the chmod command still operating in the background?

Thank You

 

[Patrick M. Hausen]

Don't use the shell in the web UI. Use ssh and screen or tmux to detach long running commands.

 

[sretalla]

perhaps also as a general aide to such a command, you're much better off using find to limit what you're doing rather than just blindly setting the attributes of files that already have what you want:
find ./ -maxdepth 5 -type f -not -perm 777 -print0 | xargs -0 chmod 777

This command (limiting the recursion to 5 levels of sub-directory... change if needed to go deeper) will happily pick up from where it left off without trying the ones already done.

 

[Patrick M. Hausen]

Additionally ine has to wonder why one would want to set permissions of ordinary files to 777?

chmod -R ugo=rwX <path> would set files to 666 and directories to 777 for example. Alternatively e.g. u=rwX,og=rX or whatever fits. The symbolic syntax is quite powerful.

 

[eewiz]

Thank you Patrick for your replies.

I am a 40 year DOS/Windows man. I never could get SSH into TrueNAS to work.
After wasting time on research I discovered that you can't SSH as the root user. Isn't that wonderful.
So I had to create a user just so I could SSH into TrueNAS just so I could perform these kinds of commands.
I got the /nonexistant home directory error when I tried to ssh into the box as the user.
So I tried to create a home directory. I did the Directories and Permissions setup to create a home directory in /mnt/pool/eds/user.
The instructions say that TrueNAS will create a new directory (containing the user's name) in the selected directory.
No new directory ever showed up. This is why I started chmod'ing 777 to everything because any time something has failed it's due to permissions.

I tried to SSH just now to see the /nonexistant home directory error but, now SSH works.
Now, I SSH in and I end up in the /mnt/pool/eds/user directory as set in the user's settings.
TrueNAS never did create a new directory for the user below the one selected in the user's settings.
My TrueNAS servers are in my home. They cannot be reached from the internet for any purpose.
I have no need for SSH except to work around the serious failure of the GUI shell locking up after it has worked a little too hard.
But, now that I can successfully SSH into the box, I realize that the total effort was a waste.
When I do chmod -R 777 /mnt/pool/eds I get the error "chmod: /mnt/pool/eds: Operation not permitted."
So SSH into a user is worthless for chmod -R 777 /mnt/pool/eds and the root user GUI shell is incapable of performing chmod -R 777 /mnt/pool/eds without crashing.
What a piece of JUNK.

As for the 777 vs 666.
Setting everything to 777 causes no errors and I am not forced to figure out how to segregate files from directories.
chmod -R 777 works and I only have to run the command once. Except for that feebly broken GUI shell.

Even if I spent the effort to understand the symbolic syntax as you suggested I still cannot accomplish the task in TrueNAS's feebly broken GUI shell.
I can't do it in a user SSH session either because I am not permitted to access /mnt from that interface.
I am left with no choice but to do the chmod -R 777 work in the GUI shell many many times.

All for now

 

[danb35]

After wasting time on research I discovered that you can't SSH as the root user.

Nonsense--but you do need to enable root logins in the SSH service settings.

When I do chmod -R 777 /mnt/pool/eds I get the error "chmod: /mnt/pool/eds: Operation not permitted."

...because you've created a dataset with ACLs, on which chmod doesn't work.

I still cannot accomplish the task in TrueNAS's feebly broken GUI shell.

No surprise there; it's not suitable for anything more than the most trivial of commands.

I can't do it in a user SSH session either because I am not permitted to access /mnt from that interface.

...or you could learn about the su command...

 

[eewiz]

Thank you danb35.

After wasting time on research I discovered that you can't SSH as the root user.

Nonsense--but you do need to enable root logins in the SSH service settings.

Thank you, Selecting "Log in as Root with Password" in the SSH service settings, permitted me to login SSH as the root user.
Now I can perform those GUI shell confounding procedures by SSH login as root.
WooWho.

I can't do it in a user SSH session either because I am not permitted to access /mnt from that interface.

...or you could learn about the su command...

Thank you for pointing out what I need.
"su -" permits the user account I created to perform the "chmod -R 777 /mnt/pool/eds" command.
The chmod command above is now running in that user's "su -" created shell.
It's hung now, obviously processing the chmod command and producing no errors.

When I do chmod -R 777 /mnt/pool/eds I get the error "chmod: /mnt/pool/eds: Operation not permitted."

...because you've created a dataset with ACLs, on which chmod doesn't work.

I do believe that "Operation not permitted." was caused by the user not having "su -" administrator privileges.
Every dataset residing below "/mnt/pool/eds" has ACLs due to being primarily accessed by Windows boxes.
I do not wish to be argumentative but, the "chmod -R 777 /mnt/pool/eds" command has been running in the user's "su -" session for more than an hour now and has produced no errors so far.
So, at this point, I see that the "chmod -R 777 /mnt/pool/eds" command is processing permissions on ACL configured datasets without producing any messages - good or bad.

By the way, "eds" is short for "Encrypted Data Set".
It took me two months of research and hard work to get my two TrueNAS servers setup with passphrase encryption, Samba, SSH, and successful replication.
Originally, encrypting the "pool" dataset was a disaster, so I created the "eds" dataset below "pool" and encrypted it.
Then everything except for the "iocage" dataset is placed inside the "eds" dataset.
Trying to encrypt the "iocage" dataset was also a disaster, so it remains unencrypted to this day.

Now, the chmod command has passed all of the "chmod: /mnt/pool/eds/iocage-shed/jails/urbj/root/lib: Read-only file system" errors and appears to be continuing.
These errors have been received from all attempts to run the chmod command and are self explanatory.
My Urbackup - "urbj" jail - appears to have been created "Read Only".
I don't know if I created the jail RO or Urbackup set everything to RO upon installation.
In any event, Urbackup works O.K., so I am not going to fix what's not broken.

The chmod is still running and has used 5:46 minutes of processing time so far.

A story: A man from the land of Windows gets on a plane to fly to the land of BSD to visit a friend who has recently moved there.
You arrive at the rental car agency at the airport after midnight.
You are now in your rental car in the agencies parking lot and you immediately recognize that cars in the land of BSD have no pedals and no steering wheel.
You know that all of the inhabitants of the land of BSD drive these cars every day.
But here you sit in a car in a foreign land and you quickly realize that even though you have been driving cars in your land of Windows for 50 years now, you have absolutely no idea how to leave the parking lot in a car built in the land of BSD.

Can you imagine what a disaster that would be if the automotive world worked like the computing world.

Thank you danb35 for your invaluable help.

All for now