FS_NEWCELL(1)

πŸ’– FS_NEWCELL β€” the manual page, but make it cute πŸ’–

okay bestie, pull up a chair, we're talking about fs_newcell from the AFS Command Reference (section 1, obviously). this one's a lowkey king and it edits your kernel's little mental list of which servers belong to which cell. let's get into it ✨


πŸ¦‹ NAME πŸ¦‹

fs_newcell β€” changes the kernel-resident list of a cell's database servers. she does exactly what it says on the tin, no cap.


🌸 SYNOPSIS 🌸

fs newcell -name <cell name> -servers <primary servers>+
    [-linkedcell <linked cell name>] [-help]

fs n -n <cell name> -s <primary servers>+
    [-l <linked cell name>] [-h]

see how fs n is just the glow-down version of fs newcell? same girl, shorter name πŸ’…


✨ DESCRIPTION ✨

so here's the vibe. fs newcell removes the Cache Manager's kernel-resident list of database server machines for whichever cell you named in the -name argument… and then replaces it with the database server machines you listed in -servers. out with the old, in with the new, periodt. πŸ’–

every time your machine reboots, the Cache Manager builds that kernel list of cells and database server machines all over again by reading the local /etc/openafs/CellServDB file. and here's the thing β€” this command does not change the CellServDB file. so any changes you make with it last only until the next reboot, unless you also go edit the file yourself. the output of the fs listcells command does show changes you made with this command though, because fs listcells consults the kernel-resident list and not the CellServDB file. slay, consistency πŸŽ€

this command can introduce a completely brand-new cell into the kernel-resident list, but she cannot make a cell inaccessible. like, it is not possible to remove a cell's entry from the kernel-resident list by just providing no values for the -server argument. nope. if you actually want a cell gone-gone, remove its entry from the CellServDB file and reboot the machine. that's the only way, bestie 😭

now the -linkedcell argument β€” it specifies the name of the AFS cell to link to another AFS cell for the purpose of retrying volume lookups. when two cells are linked, a volume lookup in one cell that fails gets retried in the linked cell. it's giving backup plan energy, and honestly? iconic 🫢


⚠️ CAUTIONS ⚠️

listen up because this one's important, no skipping πŸ™ˆ

some commands β€” like the aklog or klog.krb5 commands β€” work correctly only when the information is accurate for a cell in both the CellServDB file and the kernel-resident list. so if you half-do it, those commands will not be your friend. keep both sides matching, okay? πŸ’œ


πŸ’… OPTIONS πŸ’…

  • -name <cell name> β€” specifies the fully-qualified cell name of the AFS or DCE cell. give her the whole name, don't be shy ✨
  • -servers <primary servers>+ β€” specifies the fully-qualified hostnames of all the AFS database server machines for the cell named by the -name argument. yes, all of them πŸ’–
  • -linkedcell <linked cell name> β€” specifies the name of the AFS cell to link to another AFS cell for the purpose of retrying volume lookups. when two cells are linked, a volume lookup in one cell that fails is retried in the linked cell. so as you can see, when two cells are linked, a volume lookup in one cell that fails is retried in the linked cell πŸ“Ž (yes i said it twice, it's that important)
  • -help β€” prints the online help for this command. all other valid options are ignored. she said "i'm helping, nothing else matters" πŸ’€

πŸͺŸ WINDOWS πŸͺŸ

plot twist bestie, the fs newcell command on Windows is not the same girl as the Unix version. she differs in a few ways πŸ‘‘

first up: fs newcell with no arguments at all discards the existing cell information. the Windows client will reload a cell's information the next time it needs the server list for a cell. so it's not gone forever, it just gets re-fetched when needed 🌈

secondly, on top of accepting all the Unix options, fs newcell on Windows also accepts these:

  • -dns β€” adds the new cell to the cache manager, and obtains the VLDB server information from DNS 🌐
  • -registry β€” adds the new cell to the cache manager, and also saves the cell configuration data in the registry for use the next time the service restarts πŸ’Ύ
  • -vlport <cell VLDB server port> β€” specifies an alternate port number at which the cell's volume location database servers are listening πŸ”Œ
  • -fsport <cell fileserver port> β€” specifies an alternate port number at which the cell's file servers are listening πŸ”Œ

πŸ“ EXAMPLES πŸ“

example one! this changes the machine's kernel-resident list of database server machines for the Example Corporation cell so it includes the machines db1.example.com and db2.example.com:

% fs newcell -name example.com -servers db1.example.com db2.example.com

example twooo! this links the AFS cell dce.example.com to the AFS cell example.com. the AFS client contacts the Volume Location (VL) servers db1.dce.example.com and db2.dce.example.com for volume location information:

% fs newcell -name dce.example.com \
    -servers db1.dce.example.com db2.dce.example.com \
    -linkedcell example.com

look at that backslash doing its little line-continuation dance πŸ”₯ the way that \ holds it all together… obsessed.


πŸ‘‘ PRIVILEGE REQUIRED πŸ‘‘

the issuer must be logged in as the local superuser root.

that's the whole requirement. be root or go home, bestie πŸ’€


πŸ”— SEE ALSO πŸ”—

go read those too, they're part of the friend group πŸ¦‹


IBM Corporation 2000. <http://www.ibm.com/> All Rights Reserved.

This documentation is covered by the IBM Public License Version 1.0. It was converted from HTML to POD by software written by Chas Williams and Russ Allbery, based on work by Alf Wachsmann and Elizabeth Cassell.


okay that's the whole page!! πŸ’– this was OpenAFS, dated 2026-07-27, and honestly? she ate. no crumbs. go forth and know your cells, bestie πŸŽ€βœ¨πŸ«Ά

πŸ“¦ where this page comes from